View AM79C940JIW_1374330.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

final publication# 16235 rev: e amendment/ 0 i s sue dat e : m ay 2 0 00 am79c940 media access controller for ethernet (mace?) distinctive characteristics integrated controller with manchester encoder/decoder and 10base-t transceiver and aui port supports ieee 802.3/ansi 8802-3 and ethernet standards 84-pin plcc and 100-pin pqfp packages 80-pin thin quad flat pack (tqfp) package available for space critical applications such as pcmcia modular architecture allows easy tuning to specific applications high speed, 16-bit synchronous host system interface with 2 or 3 cycles/transfer individual transmit (136 byte) and receive (128 byte) flfos provide increase of system latency and support the following features: ? automatic retransmission with no fifo reload ? automatic receive stripping and transmit padding (individually programmable) ? automatic runt packet rejection ? automatic deletion of collision frames ? automatic retransmission with no fifo reload direct slave access to all on board configuration/status registers and transmit/ receive flfos direct fifo read/write access for simple interface to dma controllers or l/o processors arbitrary byte alignment and little/big endian memory interface supported internal/external loopback capabilities external address detection interface (eadi ? ) for external hardware address filtering in bridge/router applications jtag boundary scan (ieee 1149.1) test access port interface for board level production test integrated manchester encoder/decoder digital attachment interface (dai ? ) allows by-passing of differential attachment unit interface (aui) supports the following types of network interface: ? aui to external 10base2, 10base5 or 10base-f mau ? dai port to external 10base2, 10base5, 10base-t, 10base-f mau ? general purpose serial interface (gpsi) to external encoding/decoding scheme ? internal 10base-t transceiver with automatic selection of 10base-t or aui port sleep mode allows reduced power consump- tion for critical battery powered applications 5 mhz-25 mhz system clock speed support for operation in industrial temperature range ( ? 40 c to +85 c) available in all three packages general description the media access controller for ethernet (mace) chip is a cmos vlsi device designed to provide flexibility in customized lan design. the mace device is specif- ically designed to address applications where multiple i/o peripherals are present, and a centralized or sys- tem specific dma is required. the high speed, 16-bit synchronous system interface is optimized for an exter- nal dma or i/o processor system, and is similar to many existing peripheral devices, such as scsi and serial link controllers. the mace device is a slave register based peripheral. all transfers to and from the system are performed using simple memory or i/o read and write commands. in conjunction with a user defined dma engine, the mace chip provides an ieee 802.3 interface tailored to a specific application. its superior modular architec- ture and versatile system interface allow the mace device to be configured as a stand-alone device or as a connectivity cell incorporated into a larger, integrated system.
2 am79c940 the mace device provides a complete ethernet node solution with an integrated 10base-t transceiver, and supports up to 25-mhz system clocks. the mace device embodies the media access control (mac) and physical signaling (pls) sub-layers of the ieee 802.3 standard, and provides an ieee defined attach- ment unit interface (aui) for coupling to an external medium attachment unit (mau). the mace device is compliant with 10base2, 10base5, 10base-t, and 10base-f transceivers. additional features also enhance over-all system design. the individual transmit and receive fifos optimize system overhead, providing substantial latency during packet transmission and reception, and minimizing intervention during normal network error recovery. the integrated manchester encoder/decoder eliminates the need for an external serial interface adapter (sia) in the node system. if support for an external encoding/decoding scheme is desired, the general purpose serial interface (gpsi) allows direct access to/from the mac. in addition, the digital attach- ment interface (dai), which is a simplified electrical attachment specification, allows implementation of maus that do not require dc isolation between the mau and dte. the dai port can also be used to indicate transmit, receive, or collision status by connecting leds to the port. the mace device also provides an external address detection interface (eadi) to allow external hardware address filtering in internet working applications. the am79c940 mace chip is offered in a plastic leadless chip carrier (84-pin plcc), a plastic quad flat package (100-pin pqfp), and a thin quad flat package (tqfp 80-pin). there are several small func- tional and physical differences between the 80-pin tqfp and the 84-pin plcc and 100-pin pqfp config- urations. because of the smaller number of pins in the tqfp configuration versus the plcc configuration, four pins are not bonded out. though the die is identical in all three package configurations, the removal of these four pins does cause some functionality differ- ences between the tqfp and the plcc and pqfp configurations. depending on the application, the removal of these pins will or will not have an effect. (see section: ? pins removed for tqfp package and their effects.) with the rise of embedded networking applications op- erating in harsh environments where temperatures may exceed the normal commercial temperature (0 c to +70 c) window, an industrial temperature (-40 c to +85 c) version is available in all three packages; 84- pin plcc, 100-pin pqfp and 80-pin tqfp. the indus- trial temperature version of the mace ethernet control- ler is characterized across the industrial temperature range (-40 c to +85 c) within the published power supply specification (4.75 v to 5.25 v; i.e., 5% v cc ). thus, conformance of mace performance over this temperature range is guaranteed by the design and characterization monitor.
am79c940 3 block diagram c16235d-1 eadi port xtal2 eadi port control aui port 10base-t mau dai port gpsi port dxcvr clsn srdclk srd sf/bd eam/r do di ci txd txp rxd rxpol txdat txen rxdat rxcrs stdclk txdat+ txen srdclk rxdat rxcrs clsn aui 10base-t dai port gpsi r/w dbus 15 ? 0 add 4 ? 0 bus interface unit tc edsel sclk intr be 1 ? 0 tdtreq tck rdtreq eof dtv cs fds sleep reset rcv fifo xmt fifo jtag port cntrl fifo control command & status registers 802.3 mac core tdi tms tdo xtal1 notes: 1. only one of the network ports aui, 10base-t, dai port or gpsi can be active at any time. some shared signals are active regardless of which network port is active, and some are reconfigured. 2. the eadi port is active at all times. lnkst
4 am79c940 table of contents am79c940 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 distinctive characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 general description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 table of contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 connection diagrams pl 084 plcc package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 connection diagrams pqr100 pqfp package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 connection diagrams pqt080 tqfp package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 ordering information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 standard products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 pin/package summary (plcc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 1 pin description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 attachment unit interface (aui) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 ci+/ci. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 di+/di. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 do+/do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 digital attachment interface (dai) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 txdat+/txdat ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 txen /txen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 transmit enable (output) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 rxdat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 rxcrs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 dxcvr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 10base-t interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 txd+, txd ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 txp+, txp ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 rxd+, rxd ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 lnkst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 rxpol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 general purpose serial interface (gpsi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 stdclk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 clsn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 external address detection interface (eadi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 sf/bd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 srd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 eam/r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 srdclk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 host system interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 dbus15-0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 add4-0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 r/w . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 rdtreq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 tdtreq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 fds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 dtv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 eof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 be1 ? 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 intr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 sclk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 edsel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 tc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 ieee 1149.1 test access port (tap) interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 tck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
am79c940 5 tms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 tdi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 tdo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 general interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 xtal1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 xtal2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 sleep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 power supply. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 dvdd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 dvss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 avdd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 avss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 pin functions not available with the 80-pin tqfp package . . . . . . . . . . . . . . . . . .28 pins removed for tqfp package and their effects . . . . . . . . . . . . . . . . . . . . . . . . . . .28 functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 system interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 detailed functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 block level description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 bus interface unit (biu) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 biu to fifo data path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 byte alignment for fifo read operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 biu to control and status register data path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 fifo subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 media access control (mac) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 manchester encoder/decoder (mendec) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 attachment unit interface (aui) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 digital attachment interface (dai) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 10base-t interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 twisted pair transmit function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 twisted pair receive function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 link test function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 polarity detection and reversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 twisted pair interface status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 collision detect function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 signal quality error (sqe) test (heartbeat) function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 jabber function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 external address detection interface (eadi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 internal/external address recognition capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 general purpose serial interface (gpsi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 ieee 1149.1 test access port interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 6 slave access operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 read access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 write access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 reinitialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 transmit operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 transmit fifo write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 transmit function programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 automatic pad generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 transmit fcs generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51 transmit status information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51 transmit exception conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51 receive operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 receive fifo read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 receive function programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 automatic pad stripping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 receive fcs checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
6 am79c940 receive status information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 receive exception conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 loopback operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 user accessible registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 7 8-bit registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 programmer ? s register model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76 missing table title? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 system applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 host system examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 external address detection interface (eadi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 mace compatible aui isolation transformers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 manufacturer contact information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 absolute maximum ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 0 operating ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 commercial (c) devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 industrial (i) devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 v cc supply voltages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 dc characteristics (unless otherwise noted, parametric values are the same between commercial devices and industrial devices.) . . . . . . . . . . . . . . . . . . . . . . .90 ac characteristics (unless otherwise noted, parametric values are the same between commercial devices and industrial devices.) . . . . . . . . . . . . . . . . . . . . . . .93 key to switching waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97 switching test circuits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98 physical dimensions* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 pl 084 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 84-pin plastic leaded chip carrier (measured in inches) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 physical dimensions* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 pqr100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 100-pin plastic quad flat pack; trimmed and formed (measured in millimeters) . . . . . . . . . . . 118 physical dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 pqr100 100-pin plastic quad flat pack with molded carrier ring (measured in millimeters) . 119 physical dimensions* pqt080 80-pin thin quad flat package (measured in millimeters)120 logical address filtering for ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 bsdl description of am79c940 mace jtag structure . . . . . . . . . . . . . . . . . . . . . . . . .123 am79c940 mace rev c0 silicon errata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
am79c940 7 connection diagrams pl 084 plcc package 1 2 381 82 83 84 6 7 8 94 58076 77 78 79 75 12 13 14 15 16 17 18 19 20 21 23 24 25 26 27 28 29 30 31 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 43 42 41 40 47 46 45 44 37 36 35 34 39 38 33 48 52 51 50 49 10 22 11 32 53 74 srdclk eam/r srd sf/bd reset sleep dv dd intr tc dbus0 dv ss dbus1 dbus2 dbus3 dbus4 dv ss dbus5 dbus6 dbus7 dbus8 dbus9 xtal2 av ss xtal1 av dd txd+ txp+ txd- txp- av dd rxd+ rxd- dv dd tdi dv ss tck tms tdo lnkst rxpol cs r/ w rxcrs rxdat clsn txen/ txen stdclk dv ss txdat- txdat+ dv ss edsel dxcvr dv dd av dd ci+ ci- di+ di- av dd do+ do- av ss dbus10 dbus11 dbus12 dbus13 dv dd dbus14 dbus15 dv ss eof dtv fds be0 be1 sclk tdtreq rdtreq add0 add1 add2 add3 add4 am79c940jc mace 16235d-2
8 am79c940 connection diagrams pqr100 pqfp package rxcrs rxdat clsn txen/txen stdclk dv ss txdat- txdat+ dv ss edsel dxcvr dv dd av dd ci+ ci- di+ di- av dd do+ do- 28 29 30 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 1 2 3 99 98 100 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 97 96 95 94 93 92 91 90 89 88 87 86 85 84 82 81 83 tck tms tdo lnkst rxpol cs r/w nc nc nc nc av ss nc nc nc xtal2 av ss xtal1 av dd txd+ txp+ txd txp av dd rxd+ rxd dv dd tdi dv ss nc 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 80 79 78 nc nc nc nc srdclk eam/r srd sf/bd reset sleep dv dd intr tc dbus0 dv ss dbus1 dbus2 dbus3 dbus4 dv ss dbus5 dbus6 dbus7 dbus8 dbus9 nc nc nc dbus10 nc dbus11 dbus12 dbus13 dv dd dbus14 dbus15 dv ss eof dtv fds be0 be1 sclk tdtreq rdtreq add0 add1 add2 add3 add4 mace am79c940kc 16235d-3
am79c940 9 connection diagrams pqt080 tqfp package 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 srdclk eam/r sf/bd reset sleep dv dd intr tc dbus0 dv ss dbus1 dbus2 dbus3 dbus4 dv ss dbus5 dbus6 dbus7 dbus8 dbus9 xtal2 av ss xtal1 av dd txd+ txp+ txd- txp- av dd rxd+ rxd- dv dd tdi dv ss tck tms td0 lnkst cs r/w dbus10 dbus11 dbus12 dbus13 dv dd dbus14 dbus15 dv ss eof fds be0 be1 sclk tdtreq rdtreq add0 add1 add2 add3 add4 rxcrs rxdat clsn txen/ stdclk dv ss txdat+ dv ss edsel dxcvr dv dd av dd ci+ ci- di+ di- av dd do+ do- av ss mace am79c940vc notes: four pin functions available on the plcc and pqfp packages are not available with the tqfp package. (see full data sheet for description of pins not included with the 80-pin tqfp package. in particular, see section ?pin functions not available with the 80-pin tqfp package.?) 16235d-4
10 am79c940 ordering information standard products amd standard products are available in several packages and operating ranges. the order number (valid combination) is formed by a combination of: valid combinations the valid combinations table lists configurations planned to be supported in volume for this device. consult the local amd sales office to confirm availability of specific valid combinations and to check on newly released combinations. note: currently the silicon revision level of the mace ethernet controller is revision c0. this is designated by the marking on the p ackage as am79c940bxx, where ? xx ? indicate package type and temperature range. am79c940 optional processing blank = standard processing temperature range c= commercial (0 to +70 c) i = industrial (-40 c to +85 c) package type (per prod. nomenclature/16-038) j = 84-pin plastic leaded chip carrier (pl 084) k = 100-pin plastic quad flat pack (pqr100) v = 80-pin thin quad flat package (pqt080) speed not applicable device number/description (include revision letter) am79c940 media access controller for ethernet vc alternate packaging option \w = trimmed and formed in a tray \w valid combinations am79c940 jc, kc, kc\w, vc, vc\w am79c940 ji, ki, ki\w, vi, vi\w
am79c940 11 pin/package summary (plcc) plcc pin # pin name pin function 1 dxcvr disable transceiver 2 edsel edge select 3dv ss digital ground 4 txdat+ transmit data + 5txdat ? transmit data ? 6dv ss digital ground 7 stdclk serial transmit data clock 8 txen/txen transmit enable 9 clsn collision 10 rxdat receive data 11 rxcrs receive carrier sense 12 srdclk serial receive data clock 13 eam/r external address match/reject 14 srd serial receive data 15 sf/bd start frame/byte delimiter 16 reset reset 17 sleep sleep mode 18 dv dd digital power 19 intr interrupt 20 tc timing control 21 dbus0 data bus0 22 dv ss digital ground 23 dbus1 data bus1 24 dbus2 data bus2 25 dbus3 data bus3 26 dbus4 data bus4 27 dv ss digital ground 28 dbus5 data bus5 29 dbus6 data bus6 30 dbus7 data bus7 31 dbus8 data bus8 32 dbus9 data bus9 33 dbus10 data bus10 34 dbus11 data bus11 35 dbus12 data bus12 36 dbus13 data bus13 37 dv dd digital power 38 dbus14 data bus14 39 dbus15 data bus15 40 dv ss digital ground 41 eof end of frame 42 dtv data transfer valid 43 fds fifo data strobe 44 be0 byte enable0
12 am79c940 pin/package summary (continued) plcc pin # pin name pin function 45 be1 byte enable 1 46 sclk system clock 47 tdtreq transmit data transfer request 48 rdtreq receive data transfer request 49 add0 address0 50 add1 address1 51 add2 address2 52 add3 address3 53 add4 address4 54 r/w read/write 55 cs chip select 56 rxpol receive polarity 57 lnkst link status 58 tdo test data out 59 tms test mode select 60 tck test clock 61 dv ss digital ground 62 tdi test data input 63 dv dd digital power 64 rxd ? receive data ? 65 rxd+ receive data+ 66 av dd analog power 67 txp ? transmit pre-distortion 68 txd ? transmit data ? 69 txp+ transmit pre-distortion+ 70 txd+ transmit data+ 71 av dd analog power 72 xtal1 crystal output 73 av ss analog ground 74 xtal2 crystal output 75 av ss analog ground 76 do ? data out ? 77 do+ data out+ 78 av dd analog power 79 di ? data in ? 80 di+ data in+ 81 ci ? control in ? 82 ci+ control in+ 83 av dd analog power 84 dv dd digital power
am79c940 13 pin/package summary (pqfp) (continued) pqfp pin # pin name pin function 1 nc no connect 2 nc no connect 3 nc no connect 4 nc no connect 5 shdclk serial receive data clock 6 eam/r external address match/reject 7 srd serial receive data 8 sf/bd start frame/byte delimiter 9 reset reset 10 sleep sleep mode 11 dvdd digital power 12 intr interrupt 13 tc timing control 14 dbus0 data bus0 15 dv ss digital ground 16 dbus1 data bus1 17 dbus2 data bus2 18 dbus3 data bus3 19 dbus4 data bus4 20 dv ss digital ground 21 dbus5 data bus5 22 dbus6 data bus6 23 dbus7 data bus7 24 dbus8 data bus8 25 dbus9 data bus9 26 nc no connect 27 nc no connect 28 nc no connect 29 dbus10 data bus10 30 nc no connect 31 dbus11 data bus11 32 dbus12 data bus12 33 dbus13 data bus13 34 dv dd digital power 35 dbus14 data bus14 36 dbus15 data bus15 37 dv ss digital ground 38 eof end of frame 39 dtv data transfer valid 40 fds fifo data strobe 41 be0 byte enable0 42 be1 byte enable1
14 am79c940 pin/package summary (continued) pqfp pin # pin name pin function 43 sclk system clock 44 tdtreq transmit data transfer request 45 rdtreq receive data transfer request 46 add0 address0 47 add1 address1 48 add2 address2 49 add3 address3 50 add4 address4 51 nc no connect 52 nc no connect 53 nc no connect 54 nc no connect 55 r/w read/write 56 cs chip select 57 rxpol receive polarity 58 lnkst link status 59 tdo test data out 60 tms test mode select 61 tck test clock 62 dv ss digital ground 63 tdi test data input 64 dv dd digital power 65 rxd ? receive data ? 66 rxd+ receive data+ 67 av dd analog power 68 txp ? transmit pre-distortion ? 69 txd ? transmit data ? 70 txp+ transmit pre-distortion+ 71 txd+ transmit data+ 72 av dd analog power 73 xtal1 crystal input 74 av ss analog ground 75 xtal2 crystal output 76 nc no connect 77 nc no connect 78 nc no connect 79 av ss analog ground 80 nc no connect 81 do ? data out ? 82 do+ data out+ 83 av dd analog power 84 di ? data in ? 85 di+ data in+
am79c940 15 pin/package summary (continued) pqfp pin # pin name pin function 86 ci ? control in ? 87 ci+ control in+ 88 av dd analog power 89 dv dd digital power 90 dxcvr disable transceiver 91 edsel edge select 92 dv ss digital ground 93 txdat+ transmit data + 94 txdat ? transmit data ? 95 dv ss digital ground 96 stdclk serial transmit data clock 97 txen/txen transmit enable 98 clsn collision 99 rxdat receive data 100 rxcrs receive carrier sense
16 am79c940 pin/package summary (tqfp) (continued) tqfp # pin name pin function tqfp pin number pin name pin function 1 srdclk serial receive data clock 41 r/w read/write 2 eam/r external address match/reject 42 cs chip/select 3 sf/bd start frame/byte delimiter 43 lnkst link status 4 reset reset 44 tdo test data out 5sleep sleep mode 45 tms test mode select 6 dvdd digital power 46 tck text clock 7intr interrupt 47 dvss digital ground 8tc timing control 48 tdi test data input 9 dbus0 data bus0 49 dvdd digital power 10 dvss digital ground 50 rxd ? receive data ? 11 dbus1 data bus1 51 rxd+ receive data+ 12 dbus2 data bus2 52 avdd analog power 13 dbus3 data bus3 53 txp ? transmit pre-distortion ? 14 dbus4 data bus4 54 txd ? transmit data ? 15 dvss digital ground 55 txp+ transmit pre-distortion+ 16 dbus5 data bus5 56 txd+ transmit data+ 17 dbus6 data bus6 57 avdd analog power 18 dbus7 data bus7 58 xtal1 crystal output 19 dbus8 data bus8 59 avss analog ground 20 dbus9 data bus9 60 xtal2 crystal output 21 dbus10 data bus10 61 avss analog ground 22 dbus11 data bus11 62 do ? data out ? 23 dbus12 data bus12 63 do+ data out+ 24 dbus13 data bus13 64 avdd analog power 25 dvdd digital power 65 di ? data in ? 26 dbus14 data bus14 66 di+ data out+ 27 dbus15 data bus15 67 ci ? control in ? 28 dvss digital ground 68 ci+ control in+ 29 eof end of frame 69 avdd analog power 30 fds fifo data strobe 70 dvdd digital power 31 be0 byte enable0 71 dxcvr disable transceiver 32 be1 byte enable1 72 edsel edge select 33 sclk system clock 73 dvss digital ground 34 tdtreq transmit data transfer request 74 txdat+ transmit data+ 35 rdtreq receive data transfer request 75 dvss digital ground 36 add0 address0 76 stdclk serial transmit data clock 37 add1 address1 77 txen/txen transmit enable 38 add2 address2 78 clsn collision 39 add3 address3 79 rxdat receive data 40 add4 address4 80 rxcrs receive carrier sense
am79c940 17 pin summary pin name pin function type active comment attachment unit interface (aui) do+/do ? data out o pseudo-ecl di+/di ? data in i pseudo-ecl ci+/ci ? control in i pseudo-ecl rxcrs receive carrier sense i/o high ttl output. input in dai, gpsi port txen transmit enable o high ttl. txen in dai port clsn collision i/o high ttl output. input in gpsi dxcvr disable transceiver o low ttl low stdclk serial transmit data clock i/o output. input in gpsi srdclk serial receive data clock i/o output. input in gpsi digital attachment interface (dai) txdat+ transmit data + o high ttl. see also gpsi txdat ? transmit data ? olowttl txen transmit enable o low ttl. see txen in gpsi rxdat receive data i ttl. see also gpsi rxcrs receive carrier sense i/o high ttl input. output in aui clsn collision i/o high ttl output. input in gpsi dxcvr disable transceiver o high ttl high stdclk serial transmit data clock i/o output. input in gpsi srdclk serial receive data clock i/o output. input in gpsi 10base-t interface txd+/txd ? transmit data o txp+/txp ? transmit pre-distortion o rxd+/rxd ? receive data i lnkst link status o low open drain rxpol receive polarity o low open drain txen transmit enable o high ttl. txen in dai port rxcrs receive carrier sense i/o high ttl output. input in dai, gpsi port clsn collision i/o high ttl output. input in gpsi dxcvr disable transceiver o high ttl high stdclk serial transmit data clock i/o output. input in gpsi srdclk serial receive data clock i/o output. input in gpsi general purpose serial interface (gpsi) stdclk serial transmit data clock i/o input txdat+ transmit data + o high ttl. see also dai port txen transmit enable o high ttl. txen in dai port srdclk serial receive data clock i/o input. see also eadi port rxdat receive data i ttl. see also dai port rxcrs receive carrier sense i/o high ttl input. output in aui clsn collision i/o high ttl input dxcvr disable transceiver o low ttl low
18 am79c940 pin summary (continued) pin name pin function type active comment external address detection interface (eadi) sf/bd start frame/byte delimiter o high srd serial receive data o high eam/r external address match/reject i low srdclk serial receive data clock i/o output except in gpsi host system interface dbus 15 ? 0 data bus i/o high add4 ? 0address i high r/w read/write i high/low rdtreq receive data transfer request o low tdtreq transmit data transfer request o low dtv data transfer valid o low tristate eof end of frame i/o low be0 byte enable 0 i low be1 byte enable 1 i low cs chip select i low fds fifo data strobe i low intr interrupt o low open drain edsel edge select i high tc timing control i low internal pull-up sclk system clock i high reset reset i low ieee 1149.1 test access port (tap) interface tck test clock i internal pull-up tms test mode select i internal pull-up tdi test data input i internal pull-up tdo test data out o general interface xtal1 crystal input i cmos xtal2 crystal output o cmos sleep sleep mode i low ttl dv dd digital power (4 pins) p dv ss digital power (6 pins) p av dd analog power (4 pins) p av ss analog power (2 pins) p
am79c940 19 pin description network interfaces the mace device has five potential network inter- faces. only one of the interfaces that provides physical network attachment can be used (active) at any time. selection between the aui, 10base-t, dai or gpsi ports is provided by programming the phy configura- tion control register. the eadi port is effectively active at all times. some signals, primarily used for status reporting, are active for more than one single interface (the clsn pin for instance). under each of the descrip- tions for the network interfaces, the primary signals which are unique to that interface are described. where signals are active for multiple interfaces, they are described once under the interface most appropri- ate. attachment unit interface (aui) ci+/ci control in (input) a differential input pair, signaling the mace device that a collision has been detected on the network media, in- dicated by the ci inputs being exercised with 10 mhz pattern of sufficient amplitude and duration. operates at pseudo-ecl levels. di+/di data in (input) a differential input pair to the mace device for receiv- ing manchester encoded data from the network. operates at pseudo-ecl levels. do+/do data out (output) a differential output pair from the mace device for transmitting manchester encoded data to the network. operates at pseudo-ecl levels. digital attachment interface (dai) txdat+/txdat ? transmit data (output) when the dai port is selected, txdat are configured as a complementary pair for manchester encoded data output from the mace device, used to transmit data to a local external network transceiver. during valid trans- mission (indicated by txen low), a logical 1 is indi- cated by the txdat+ pin being in the high state and txdat ? in the low state; and a logical 0 is indicated by the txdat+ pin being in the low state and txdat ? in the high state. during idle (txen high), txdat+ will be in the high state, and txdat ? in the low state. when the gpsi port is selected, txdat+ will provide nrz data output from the mac core, and txdat ? will be held in the low state. operates at ttl levels. the operations of txdat+ and txdat ? are defined in the following tables: txdat + configuration txdat ? configuration notes: 1. portsel [1 ? 0] and enplsio are located in the pls configuration control register (reg addr 14). 2. this pin should be externally terminated, if unused, to reduce power consumption. sleep portsel [1-0] endplsio interface description pin function 0 xx x sleep mode high impedance 1 00 1 aui high impedance (note 2) 1 01 1 10base ? t high impedance (note 2) 1101dai port txdat+ output 1111gpsi txdat+ output 1 xx 0 status disabled high impedance (note 2) sleep portsel [1-0] endplsio interface description pin function 0 xx x sleep mode high impedance 1 00 1 aui high impedance 1 01 1 10base ? t high impedance 1101dai port txdat ? output 1111gpsi low 1 xx 0 status disabled high impedance
20 am79c940 txen /txen transmit enable (output) when the aui port is selected (portsel [1-0] = 00), an output indicating that the aui do differential output has valid manchester encoded data is presented. when the 10base-t port is selected (portsel [1-0] = 01), indicates that manchester data is being output on the txd /txp complementary outputs. when the dai port is selected (portsel [1 ? 0] = 10), indicates that manchester data is being output on the dai port txdat complementary outputs. when the gpsi port is selected (portsel [1 ? 0] =11), indicates that nrz data is being output from the mac core of the mace device, to an external manchester encoder/decoder, on the txdat+ output. active low when the dai port is selected, active high when the aui, 10 base-t or gpsi is selected. operates at ttl levels. rxdat receive data (input) when the dai port is selected (portsel [1 ? 0] = 10), the manchester encoded data input to the integrated clock recovery and manchester decoder of the mace device, from an external network transceiver. when the gpsi port is selected (portsel [1 ? 0] =11), the nrz decoded data input to the mac core of the mace device, from an external manchester encoder/decoder. operates at ttl levels. rxcrs receive carrier sense (input/output) when the aui port is selected (portsel [1 ? 0] = 00), an output indicating that the di input pair is receiving valid manchester encoded data from the external transceiver which meets the signal amplitude and pulse width requirements. when the 10base-t port is selected (portsel [1 ? 0] = 01), an output indicating that the rxd input pair is receiving valid manchester encoded data from the twisted pair cable which meets the signal amplitude and pulse width requirements. rxcrs will be asserted high for the entire duration of the receive message. when the dai port is selected (portsel [1-0] = 10), an input signaling the mace device that a receive carrier condition has been detected on the network, and valid manchester encoded data is being presented to the mace device on the rxdat line. when the gpsi port is selected (portsel [1-0] = 11), an input signalling the internal mac core that valid nrz data is being presented on the rxdat input. operates at ttl levels. txen /txen configuration notes: 1. portsel [1 ? 0] and enplsio are located in the pls configuration control register (reg addr 14). 2. when the gpsi port is selected, txen should have an external pull-down attached (e.g. 3.3k ? ) to ensure the output is held inactive before enplsio is set. 3. this pin should be externally terminated, if unused, to reduce power consumption. sleep portsel [1-0] endplsio interface description pin function 0 xx x sleep mode high impedance 1 00 1 aui txen output 1 01 1 10base-t txen output 1 10 1 dai port txen output 1 11 1 gpsi txen output 1 xx 0 status disabled high impedance (note 3)
am79c940 21 rxdat configuration notes: 1. portsel [1 ? 0] and enplsio are located in the pls configuration control register (reg addr 14). 2. this pin should be externally terminated, if unused, to reduce power consumption. rxcrs configuration notes: 1. portsel [1 ? 0] and enplsio are located in the pls configuration control register (reg addr 14). 2. this pin should be externally terminated, if unused, to reduce power consumption. dxcvr disable transceiver (output) an output from the mace device to indicate the net- work port in use, as programmed by the asel bit or the portsel [1 ? 0] bits. the output is provided to allow power down of an external dc-to-dc converter, typi- cally used to provide the voltage requirements for an external 10base2 transceiver. when the auto select (asel) feature is enabled, the state of the portsel [1 ? 0] bits is overridden, and the network interface will be selected by the mace device, dependent only on the status of the 10base-t link. if the link is active (lnkst pin driven low) the 10base-t port will be used as the active network inter- face. if the link is inactive (lnkst pin pulled high) the aui port will be used as the active network interface. auto select will continue to operate even when the sleep pin is asserted if the rwake bit has been set. the awake bit does not allow the auto select func- tion, and only the receive section of 10base-t port will be active (dxcvr = high). active (high) when either the 10base-t or dai port is selected. inactive (low) when the aui or gpsi port is selected. sleep portsel [1 ? 0] enplsio interface description pin function 0 xx x sleep mode high impedance 1 00 1 aui high impedance (note 2) 1 01 1 10base-t high impedance (note 2) 1 10 1 dai port rxdat input 1 11 1 gpsi rxdat input 1 xx 0 status disabled high impedance (note 2) sleep portsel [1-0] endplsio interface description pin function 0 xx x sleep mode high impedance 1001aui rxcrs output 1 01 1 10base-t rxcrs output 1 10 1 dai port rxcrs output 1 11 1 gpsi rxcrs output 1 xx 0 status disabled high impedance (note 2)
22 am79c940 dxcvr configuration ? sleep operation note: 1. rwake and asel are located in the phy configuration control register (reg addr 15). portsel [1 ? 0] and enplsio are located in the pls configuration control register (reg addr 14). all bits must be programmed prior to the assertion of the sleep pin. dxcvr configuration ? normal operation note: 1. rwake and asel are located in the phy configuration control register (reg addr 15). portsel [1 ? 0] and enplsio are located in the pls configuration control register (reg addr 14). sleep pin rwake bit awake bit asel bit lnkst pin portsel [1 ? 0] bits interface description pin function 00 0x high impedance xx sleep mode high impedance 01 00 high impedance 00 aui with eadi port low 01 00 high impedance 01 10base-t with eadi port high 01 00 high impedance 10 invalid high 01 00 high impedance 11 invalid low 01 01 high impedance 0x aui with eadi port low 01 01 high impedance 0x 10base-t with eadi port high 0 1 1 1 high 0x aui with eadi port low 0 1 1 1 low 0x 10base-t with eadi port high 0 0 1 x x 0x 10base-t high sleep pin asel bit lnkst pin portsel [1-0] bits enplsio bit interface description pin function 1 x x xx x sia test mode high impedance 10 x 00 x aui low 1 0 x 01 x 10base-t high 1 0 x 10 x dai port high 1 0 x 11 x gpsi low 1 1 high 0x x aui low 1 1 low 0x x 10base-t high
am79c940 23 10base-t interface txd+, txd ? transmit data (output) 10base ? t port differential drivers. txp+, txp ? transmit pre-distortion (output) transmit wave form differential driver for pre-distortion. rxd+, rxd ? receive data (input) 10base ? t port differential receiver. these pins should be externally terminated to reduce power consumption if the 10base ? t interface is not used. lnkst link status (outputopen drain) this pin is driven low if the link is identified as func- tional. if the link is determined to be nonfunctional, due to missing idle link pulses or data packets, then this pin is not driven (requires external pull-up). in the low output state, the pin is capable of sinking a maximum of 12 ma and can be used to drive an led. this feature can be disabled by setting the disable link test (dlnktst) bit in the phy configuration control register. in this case the internal link test receive function is disabled, the lnkst pin will be driven low, and the transmit and receive functions will remain active regardless of arriving idle link pulses and data. the internal 10base-t mau will continue to generate idle link pulses irrespective of the status of the dlnktst bit. rxpol receive polarity (output, open drain) the twisted pair receiver is capable of detecting a receive signal with reversed polarity (wiring error). the rxpol pin is normally in the low state, indicating correct polarity of the received signal. if the receiver detects a received packet with reversed polarity, then this pin is not driven (requires external pull-up) and the polarity of subsequent packets are inverted. in the low output state, this pin is capable of sinking a maximum of 12ma and can be used to drive an led. the polarity correction feature can be disabled by setting the disable auto polarity correction (dapc) bit in the phy configuration control register. in this case, the receive polarity correction circuit is disabled and the internal receive signal remains non-inverted, irrespective of the received signal. note that rxpol will continue to reflect the polarity detected by the receiver. general purpose serial interface (gpsi) stdclk serial transmit data clock (input/output) when either the aui, 10base ? t or dai port is selected, stdclk is an output operating at one half the crystal or xtal1 frequency. stdclk is the encoding clock for manchester data transferred to the output of either the aui do pair, the 10base-t txd /txp pairs, or the dai port txdat pair. when using the gpsi port, stdclk is an input at the network data rate, provided by the external manchester encode/decoder, to strobe out the nrz data presented on the txdat+ output. this is also required for internal loopbacks while in gpsi mode. stdclk configuration notes: 1. portsel [1 ? 0] and enplsio are located in the pls configuration control register (reg addr 14). 2. this pin should be externally terminated, if unused, to reduce power consumption. sleep portsel [1-0] endplsio interface description pin function 0 xx x sleep mode high impedance 1001aui stdclk output 1 01 1 10base-t stdclk output 1 10 1 dai port stdclk output 1 11 1 gpsi stdclk output 1 xx 0 status disabled high impedance (note 2)
24 am79c940 clsn collision (input/output) an external indication that a collision condition has been detected by the (internal or external) medium attachment unit (mau), and that signals from two or more nodes are present on the network. when the aui port is selected (portsel [1 ? 0] = 00), clsn will be activated when the ci input pair is receiving a collision indication from the external transceiver. clsn will be asserted high for the entire duration of the collision detection, but will not be asserted during the sqe test message following a transmit message on the aui. when the 10base-t port is selected (portsel [1 ? 0] = 01), clsn will be asserted high when simultaneous transmit and receive activity is detected (logically detected when txd /txp and rxd are both active). when the dai port is selected (portsel [1 ? 0] = 10), clsn will be asserted high when simultaneous trans- mit and receive activity is detected (logically detected when rxcrs and txen are both active). when the gpsi port is selected (portsel [1 ? 0] = 11), an input from the external manchester encoder/decoder signal- ing the mace device that a collision condition has been detected on the network, and any receive frame in progress should be aborted. external address detection interface (eadi) sf/bd start frame/byte delimiter (output) the external indication that a start of frame delimiter has been received. the serial bit stream will follow on the serial receive data pin (srd), commencing with the destination address field. sf/bd will go high for 4 bit times (400 ns) after detecting the second 1 in the sfd of a received frame. sf/bd will subsequently toggle every 400 ns (1.25 mhz frequency) with the rising edge indicating the start (first bit) in each subsequent byte of the received serial bit stream. sf/bd will be inactive during frame transmission. srd serial receive data (output) srd is the decoded nrz data from the network. it is available for external address detection. note that when the 10base-t port is selected, transition on srd will only occur during receive activity. when the aui or dai port is selected, transition on srd will occur dur ing both transmit and receive activity. clsn configuration notes: 1. portsel [1 ? 0] and enplsio are located in the pls configuration control register (reg addr 14). 2. this pin should be externally terminated, if unused, to reduce power consumption. eam/r external address match/reject (input) the incoming frame will be received dependent on the receive operational mode of the mace device, and the polarity of the eam/r pin. the eam/r pin function is programmed by use of the m/r bit in the receive frame control register. if the bit is set, the pin is config- ured as eam . if the bit is reset, the pin is configured as ear . eam/r can be asserted during packet reception to accept or reject packets based on an external address comparison. srdclk serial receive data clock (input/output) the serial receive data (srd) output is synchronous to srdclk running at the 10mhz receive data clock frequency. the pin is configured as an input, only when the gpsi port is selected. note that when the 10base ? t port is selected, transition on srdclk will only occur during receive activity. when the aui or dai port is selected, transition on srdclk will occur during both transmit and receive activity. sleep portsel [1-0] endplsio interface description pin function 0 xx x sleep mode high impedance 1 00 1 aui clsn output 1 01 1 10base-t clsn output 1101dai port clsn output 1 11 1 gpsi clsn output 1 xx 0 status disabled high impedance (note 2)
am79c940 25 srd configuration note: 1. portsel [1 ? 0] and enplsio are located in the pls configuration control register (reg addr 14). srdclk configuration notes: 1. portsel [1 ? 0] and enplsio are located in the pls configuration control register (reg addr 14). 2. this pin should be externally terminated, if unused, to reduce power consumption. sleep portsel [1-0] endplsio interface description pin function 0 xx x sleep mode high impedance 1001aui srd output 1 01 1 10base-t srd output 1 10 1 dai port srd output 1111gpsi srd output 1 xx 0 status disabled high impedance sleep portsel [1-0] endplsio interface description pin function 0 xx x sleep mode high impedance 1 00 1 aui srdclk output 1 01 1 10base-t srdclk output 1 10 1 dai port srdclk output 1 11 1 gpsi srdclk output 1 xx 0 status disabled high impedance (note 2)
26 am79c940 host system interface dbus15-0 data bus ( input/output/3-state) dbus contains read and write data to and from internal registers and the transmit and receive fifos. add4-0 address bus (input) add is used to access the internal registers and fifos to be read or written. r/w read/write (input) indicates the direction of data flow during the mace device register, transmit fifo, or receive fifo accesses. rdtreq receive data transfer request (output) receive data transfer request indicates that there is data in the receive fifo to be read. when rdtreq is asserted there will be a minimum of 16 bytes to be read except at the completion of the frame, in which case eof will be asserted. rdtreq can be pro- grammed to request receive data transfer when 16, 32 or 64 bytes are available in the receive fifo, by pro- gramming the receive fifo watermark (rcvfw bits) in the fifo configuration control register. the first assertion of rdtreq will not occur until at least 64 bytes have been received, and the frame has been ver- ified as non runt. runt packets will normally be deleted from the receive fifo with no external activity on rdtreq . when runt packet accept is enabled (rpa bit) in the user test register, rdtreq will be asserted when the runt packet completes, and the entire frame resides in the receive fifo. rdtreq will be asserted only when enable receive (enrcv) is set in the mac configuration control register. the rcvfw can be overridden by enabling the low latency receive function (setting llrcv bit) in the receive frame control register, which allows rdtreq to be asserted after only 12 bytes have been received. note that use of this function exposes the system interface to premature termination of the receive frame, due to network events such as collisions or runt packets. it is the responsibility of the system designer to provide adequate recovery mechanisms for these conditions. tdtreq transmit data transfer request (output) transmit data transfer request indicates there is room in the transmit fifo for more data. tdtreq is asserted when there are a minimum of 16 empty bytes in the transmit fifo. tdtreq can be programmed to request transmit data transfer when 16, 32 or 64 bytes are available in the transmit fifo, by programming the transmit fifo watermark (xmtfw bits) in the fifo configuration control register. tdtreq will be asserted only when enable transmit (enxmt) is set in the mac configuration control register. fds fifo data select (input) fifo data select allows direct access to the transmit or receive fifo without use of the add address bus. fds must be activated in conjunction with r/w . when the mace device samples r/w as high and fds low, a read cycle from the receive fifo will be initiated. when the mace chip samples r/w and fds low, a write cycle to the transmit fifo will be initiated. the cs line should be inactive (high) when fifo access is requested using the fds pin. if the mace device sam- ples both cs and fds as active simultaneously, no cycle will be executed, and dtv will remain inactive. dtv data transfer valid (output/3-state) when asserted, indicates that the read or write opera- tion has completed successfully. the absence of dtv at the termination of a host access cycle on the mace device indicates that the data transfer was unsuccess- ful. dtv need not be used if the system interface can guarantee that the latency to tdtreq and rdtreq assertion and de-assertion will not cause the transmit fifo to be over-written or the receive fifo to be over-read. in this case, the latching or strobing of read or write data can be synchronized to the sclk input rather than to the dtv output. eof end of frame (input/output/3-state) end of frame will be asserted by the mace device when the last byte/word of frame data is read from the receive fifo, indicating the completion of the frame data field for the receive message. end of frame must be asserted low to the mace device when the last byte/word of the frame is written into the transmit fifo. be1 ? 0 byte enable (input) used to indicate the active portion of the data transfer to or from the internal fifos. for word (16-bit) trans- fers, both be0 and be1 should be activated by the external host/controller. single byte transfers are per- formed by identifying the active data bus byte and acti- vating only one of the two signals. the function of the be1 -0 pins is programmed using the bswp bit (biu configuration control register, bit 6). be1 -0 are not required for accesses to mace device registers.
am79c940 27 cs chip select (input) used to access the mace device fifos and internal registers locations using the add address bus. the fifos may alternatively be directly accessed without supplying the fifo address, by using the fds and r/w pins. intr interrupt (output, open drain) an attention signal indicating that one or more of the following status flags are set: xmtint, rcvint, mpco, rpco, rcvcco, cerr, babl, or jab. each interrupt source can be individually masked. no inter- rupt condition can take place in the mace device immediately after a hardware or software reset. reset reset (input) reset clears the internal logic. reset can be asynchro- nous to sclk, but must be asserted for a minimum duration of 15 sclk cycles. sclk system clock (input) the system clock input controls the operational fre- quency of the slave interface to the mace device and the internal processing of frames. sclk is unrelated to the 20 mhz clock frequency required for the 802.3/ ethernet interface. the sclk frequency range is 1 mhz-25 mhz. edsel system clock edge select (input) edsel is a static input that allows system clock (sclk) edge selection. if edsel is tied high, the bus interface unit will assume falling edge timing. if edsel is tied low, the bus interface unit will assume rising edge timing, which will effectively invert the sclk as it enters the mace device, i.e., the address, control lines (cs , r/ w , fds , etc) and data are all latched on the ris- ing edge of sclk, and data out is driven off the rising edge of sclk. tc timing control (input) the timing control input conditions the minimum num- ber of system clocks (sclk) cycles taken to read or write the internal registers and fifos. tc can be used as a wait state generator, to allow additional time for data to be presented by the host during a write cycle, or allow additional time for the data to be latched during a read cycle. tc has an internal (sleep disabled) pull up. timing control ieee 1149.1 test access port (tap) interface tck test clock (input) the clock input for the boundary scan test mode oper- ation. tck can operate up to 10 mhz. tck has an in- ternal (not sleep disabled) pull up. tms test mode select (input) a serial input bit stream used to define the specific boundary scan test to be executed. tms has an inter- nal (not sleep disabled) pull up. tdi test data input (input) the test data input path to the mace device. tdi has an internal (not sleep disabled) pull up. tdo test data out (output) the test data output path from the mace device. general interface xtal1 crystal connection (input) the internal clock generator uses a 20 mhz crystal that is attached to pins xtal1 and xtal2. internally, the 20 mhz crystal frequency is divided by two which determines the network data rate. alternatively, an external 20 mhz cmos-compatible clock signal can be used to drive this pin. the mace device supports the use of 50 pf crystals to generate a 20 mhz frequency which is compatible with the ieee 802.3 network fre quency tolerance and jitter specifications. xtal2 crystal connection (output) the internal clock generator uses a 20 mhz crystal that is attached to pins xtal1 and xtal2. if an external clock generator is used on xtal1, then xtal2 should be left unconnected. sleep sleep mode (input) the optimal power savings made is extracted by asserting the sleep pin with both the auto wake (awake bit) and remote wake (rwake bit) functions disabled. in this ? deep sleep ? mode, all outputs will be forced into their inactive or high impedance state, and all inputs will be ignored except for the sleep , reset , sclk, tck, tms, and tdi pins. sclk must run for 5 cycles after the assertion of sleep . during the ? deep sleep ? , the sclk input can be optionally suspended for maximum power savings. upon exiting ? deep sleep ? , the hardware reset pin must be asserted and the sclk restored. the system must delay the setting tc number of clocks 12 03
28 am79c940 of the bits in the mac configuration control register of the internal analog circuits by 1 ns to allow for stabilization. if the awake bit is set prior to the activation of sleep, the 10base ? t receiver and the lnkst output pin remain operational. if the rwake bit is set prior to sleep being asserted, the manchester encoder/decoder, aui and 10base-t cells remain operational, as do the srd, srdclk and sf/bd outputs. the input on xtal1 must remain active for the awake or rwake features to operate. after exit from the auto wake or remote wake modes, activation of hardware reset is not required when sleep is reasserted. on deassertion of sleep , the mace device will go through an internally generated hardware reset sequence, requiring re-initialization of mace registers. power supply dv dd digital power there are four digital v dd pins. dv ss digital ground there are six digital v ss pins. av dd analog power there are four analog vdd pins. special attention should be paid to the printed circuit board layout to avoid excessive noise on the supply to the pll in the manchester encoder/decoder (pins 66 and 83 in plcc, pins 67 and 88 in pqfp). these supply lines should be kept separate from the dv dd lines as far back to the power supply as is practically possible. av ss analog ground there are two analog vss pins. special attention should be paid to the printed circuit board layout to avoid excessive noise on the pll supply in manches- ter encoder/decoder (pin 73 in plcc, pin 74 in pqfp). these supply lines should be kept separate from the dv ss lines as far back to the power supply as is practically possible. pin functions not available with the 80-pin tqfp package in the 84-pin plcc configuration, all the pins are used while in the 100-pin pqfp version, 16 pins are specified as no connects. moving to the 80-pin tqfp configuration requires the removal of 4 pins. since ethernet controllers with integrated 10base-t have analog portions which are very sensitive to noise, power and ground pins are not deleted. the mace device does have several sets of media interfaces which typically go unused in most designs, however. pins from some of these interfaces are deleted instead. removed are the following: txdat ? (previously used for the dai interface) srd (previously used for the eadi interface) dtv (previously used for the host interface) rxpol (previously used as a receive frame polarity led driver) note that pins from four separate interfaces are removed rather than removing all the pins from a single interface. each of these pins comes from one of the four sides of the device. this is done to maintain sym- metry, thus avoiding bond out problems. in general, the most critical of the four removed pins are txdat ? and srd. depending on the application, either the dai or the eadi interface may be important. in most designs, however, this will not be the case. pins removed for tqfp package and their effects txdat ? the removal of txdat ? means that the dai interface is no longer usable. the dai interface was designed to be used with media types that do not require dc isolation between the mau and the dte. media which do not re- quire dc isolation can be implemented more simply using the dai interface, rather than the aui interface. in most designs this is not a problem because most media requires dc isolation (10base-t, 10base2, 10base5) and will use the aui port. about the only media which does not require dc isolation is 10base-f. srd the srd pin is an output pin used by the mace device to transfer a receive data stream to external address detection logic. it is part of the eadi interface. this pin is used to help interface the mace device to an exter- nal cam device. use of an external cam is typically required when an application will operate in promiscu- ous mode and will need perfect filtering (i.e., the inter- nal hash filter will not suffice). example applications for this sort of operation are bridges and routers. lack of perfect filtering in these applications forces the cpu to be more involved in filtering and thus either slows the forwarding rates achieved or forces the use of a more powerful cpu. dtv the dtv pin is part of the host interface to the mace device. it is used to indicate that a read or write cycle to the mace device was successful. if dtv is not as- serted at the end of a cycle, the data transfer was not successful. basically, this will happen on a write to a full transmit fifo or a read from an empty receive
am79c940 29 fifo. in general, there are ways to ensure that a transfer is always valid; so this pin is not required in many designs. for instance, the tdtreq and rdtreq pins can be used to monitor the state of the fifos to ensure that data transfer only occurs at the correct times. rxpol rxpol is typically used to drive an led indicating the polarity of receive frames. this function is not necessary for correct operation of the ethernet and serves strictly as a status indication to a user. the sta- tus of the receive polarity is still available through the phycc register.
30 am79c940 functional description the media access controller for ethernet (mace) chip embodies the media access control (mac) and phys- ical signaling (pls) sub-layers of the 802.3 standard. the mace device provides the ieee defined attach- ment unit interface (aui) for coupling to remote media attachment units (maus) or on-board transceivers. the mace device also provides a digital attachment interface (dai), by-passing the differential aui interface. the system interface provides a fundamental data conduit to and from an 802.3 network. the mace de- vice in conjunction with a user defined dma engine, provides an 802.3 interface tailored to a specific application. in addition, the mace device can be combined with similarly architected peripheral devices and a multi-channel dma controller, thereby providing the system with access to multiple peripheral devices with a single master interface to memory. network interfaces the mace device can be connected to an 802.3 net- work using any one of the aui, 10 base-t, dai and gpsi network interfaces. the attachment unit inter- face (aui) provides an ieee compliant differential in- terface to a remote mau or an on-board transceiver. an integrated 10base-t mau provides a direct inter- face for twisted pair ethernet networks. the dai port can connect to local transceiver devices for 10base2, 10base-t or 10base-f connections. a general pur- pose serial interface (gpsi) is supported, which effec- tively bypasses the integrated manchester encoder/ decoder, and allows direct access to/from the integral 802.3 media access controller (mac) to provide sup- port for external encoding/decoding schemes. the in- terface in use is determined by the portsel [1-0] bits in the pls configuration control register. the eadi port does not provide network connectivity, but allows an optional external circuit to assist in receive packet accept/reject. system interface the mace device is a slave register based peripheral. all transfers to and from the device, including data, are performed using simple memory or i/o read and write commands. access to all registers, including the trans- mit and receive fifos, are performed with identical read or write timing. all information on the system inter- face is synchronous to the system clock (sclk), which allows simple external logic to be designed to interrogate the device status and control the network data flow. the receive and transmit fifos can be read or writ- ten by driving the appropriate address lines and assert- ing cs and r/w. an alternative fifo access mechanism allows the use of the fds and the r/w lines, ignoring the address lines (add 4-0 ). the state of the r/w line in conjunction with the fds input deter- mines whether the receive fifo is read (r/w high) or the transmit fifo written (r/w low). the mace de- vice system interface permits interleaved transmit and receive bus transfers, allowing the transmit fifo to be filled ( primed ) while a frame is being received from the network and/or read from the receive fifo. in receive operation, the mace device asserts receive data transfer request (rdtreq ) when the fifo con- tains adequate data. for the first indication of a new receive frame, 64 bytes must be received, assuming normal operation. once the initial 64 byte threshold has been reached, rdtreq assertion and de-assertion is dependent on the programming of the receive fifo watermark (rcvfw bits in the biu configuration con- trol register). the rdtreq can be programmed to activate when there are 16, 32 or 64 bytes of data avail- able in the receive fifo. enable receive (enrcv bit in mac configuration control register) must be set to assert rdtreq . if the runt packet accept feature is invoked (rpa bit in user test register), rdtreq will be asserted for receive frames of less than 64 bytes on the basis of internal and/or external address match only. when rpa is set, rdtreq will be asserted when the entire frame has been received or when the initial 64 byte threshold has been exceeded. see the fifo sub-systems section for further details. note that the receive fifo may not contain 64 data bytes at the time rdtreq is asserted, if the automatic pad stripping feature has been enabled (astrp rcv bit in the receive frame control register) and a mini- mum length packet with pad is received. the mace device will check for the minimum received length from the network, strip the pad characters, and pass only the data frame through the receive fifo. if the low latency receive feature is enabled (llrcv bit set in receive frame control register), rdtreq will be asserted once a low watermark threshold has been reached (12 bytes plus some additional synchro- nization time). note that the system interface will there- fore be exposed to potential disruption of the receive frame due to a network condition (see the fifo sub-system description for additional details). in transmit operation, the mace device asserts trans- mit data transfer request (tdtreq ) dependent on the programming of the transmit fifo watermark (xmtfw bits in the biu configuration control register). tdtreq will be permanently asserted when the transmit fifo is empty. the tdtreq can be pro- grammed to activate when there are 16, 32 or 64 bytes of space available in the transmit fifo. enable trans- mit (enxmt bit in mac configuration control register) must be set to assert tdtreq . write cycles to the
am79c940 31 transmit fifo will not return dtv if enxmt is dis- abled, and no data will be written. the mace device will commence the preamble sequence once the transmit start point (xmtsp bits in biu configuration control register) threshold is reached in the transmit fifo. the transmit fifo data will not be overwritten until at least 512 data bits have been transmitted onto the net- work. if a collision occurs within the slot time (512 bit time) window, the mace device will generate a jam se- quence (a 32-bit all zeroes pattern) before ceasing the transmission. the transmit fifo will be reset to point at the start of the transmit data field, and the message will be retried after the random back-off interval has expired. detailed functions block level description the following sections describe the major sub-blocks of and the external interfaces to the mace device. bus interface unit (biu) the biu performs the interface between the host or system bus and the transmit and receive fifos, as well as all chip control and status registers. the biu can be configured to accept data presented in either lit- tle-endian or big indian format, minimizing the external logic required to access the mace device internal fifos and registers. in addition, the biu directly supports 8-bit transfers and incorporates features to simplify interfacing to 32-bit systems using external latches. externally, the fifos appear as two independent reg- isters located at individual addresses. the remainder of the internal registers occupy 30 additional consecu- tive addresses, and appear as 8-bits wide. biu to fifo data path the biu operates assuming that the 16-bit data path to/from the internal fifos is configured as two inde- pendent byte paths, activated by the byte enable sig nals be0 and be1 . be0 and be1 are only used during accesses to the 16-bit wide transmit and receive fifos. after hard- ware or software reset, the bswp bit will be cleared. fifo accesses to the mace device will operate assuming an intel 80x86 type memory convention (most significant byte of a word stored in the higher addressed byte). word data transfers to/from the fifos over the dbus 15- 0 lines will have the least sig- nificant byte located on dbus 7- 0 (activated by be0 ) and the most significant byte located on dbus 15-8 (activated by be1 ). fifo data can be read or written using either byte and/ or word operations. if byte operation is required, read/write transfers can be performed on either the upper or lower data bus by asserting the appropriate byte enable. for instance with bswp = 0, reading from or writing to dbus 15-8 is accomplished by asserting be1 , and allows the data stream to be read from or written to the appropriate fifo in byte order (byte 0, byte 1,....byte n). it is equally valid to read or write the data stream using dbus 7 ? 0 and by asserting be0 . for bswp = 1, reading from or writing to dbus 15-8 is accomplished by asserting be0, and allows the byte stream to be transferred in byte order. when word operations are required, bswp ensures that the byte ordering of the target memory is compati- ble with the 802.3 requirement to send/receive the data stream in byte ascending order. with bswp = 0, the data transferred to/from the fifo assumes that byte n will be on dbus 7-0 (activated by be0 ) and byte n+1 will be on dbus 15-8 (activated by be1 ). with bswp = 1, the data transferred to/from the fifo assumes that byte n will be presented on dbus 15-8 (activated by be0 ), and byte n+1 will be on dbus 7-0 (activated by be1 ). there are some additional special cases to the above generalized rules, which are as follows: (a) when performing byte read operations, both halves of the data bus are driven with identical data, effectively allowing the user to arbitrarily read from either the upper or lower data bus, when only one of the byte enables is activated. (b) when byte write operations are performed, the transmit fifo latency is affected. see the fifo sub-system section for additional details. (c) if a word read is performed on the last data byte of a receive frame (eof is asserted), and the mes- sage contained an odd number of bytes but the host requested a word operation by asserting both be0 and be1 , then the mace device will present one valid and one non-valid byte on the data bus. the placement of valid data for the data byte is de- pendent on the target memory architecture. re- gardless of bswp, the single valid byte will be read from the be0 memory bank. if bswp = 0, be0 cor- responds to dbus7-0; if bswp = 1, be0 corre- sponds to dbus15-8. (d) if a byte read is performed when the last data byte is read for a receive frame (when the mace device activates the eof signal), then the same byte will be presented on both the upper and lower byte of the data bus, regardless of which byte enable was activated (as is the case for all byte read opera- tions). (e) when writing the last byte in a transmit message to the transmit fifo, the portion of the data bus
32 am79c940 that the last byte is transferred over is irrelevant, providing the appropriate byte enable is used. for bswp = 0, data can be presented on dbus7-0 using be0 or dbus15-8 using be1 . for bswp = 1, data can be presented on dbus7-0 using be1 or dbus15-8 using be0 . (f) when neither be0 nor be1 are asserted, no data transfer will take place. dtv will not be asserted. byte alignment for fifo read operations byte alignment for fifo write operations biu to control and status register data path all registers in the address range 2-31 are 8-bits wide. when a read cycle is executed on any of these regis- ters, the mace device will drive data on both bytes of the data bus, regardless of the programming of bswp. when a write cycle is executed, the mace device strobes in data based on the programming of bswp as shown in the tables below. all accesses to addresses 2-31 are independent of the be 0 and be 1 pins. byte alignment for register read operations byte alignment for register write operations fifo subsystem the mace device has two independent fifos, with 128-bytes for receive and 136-bytes for transmit oper- ations. the fifo sub-system contains both the fifos, and the control logic to handle normal and exception related conditions. the transmit and receive fifos interface on the net- work side with the serializer/de-serializer in the mac engine. the biu provides access between the fifos and the host system to enable the movement of data to and from the network. internally, the fifos appear to the biu as independent 16-bit wide registers. bytes or words can be written to the transmit fifo (xmtfifo), or read from the receive fifo (rcvfifo). byte and word transfers can be mixed in any order. the biu will ensure correct byte ordering dependent on the target host system, as determined by the programming of the bswp bit in the biu configuration control register. the xmtfifo and rcvfifo have three different modes of operation. these are normal (default), burst and low latency receive. default operation will be used after the hardware reset pin or software swrst bit have been activated. the remainder of this general description applies to all modes except where specific differences are noted. transmit fifo ? general operation when writing bytes to the xmtfifo, certain restric- tions apply. these restrictions have a direct influence on the latency provided by the fifo to the host system. when a byte is written to the fifo location, the entire word location is used. the unused byte is marked as a hole in the xmtfifo. these holes are skipped during the serialization process performed by the mac engine, when the bytes are unloaded from the xmtfifo. for instance, assume the transmit fifo watermark (xmtfw) is set for 32 write cycles. if the host writes byte wide data to the xmtfifo, after 36 write cycles there will be space left in the xmtfifo for only 32 more write cycles. therefore tdtreq will de-assert even though only 36-bytes of data have been loaded into the xmtfifo. transmission will not commence until 64-bytes or the end-of-frame are available in the xmfifo, so transmission would not start, and be0 be1 bswp dbus7-0 dbus15-8 00 0 n n+1 01 0 n n 10 0 n n 11 0 x x 00 1 n+1 n 01 1 n n 10 1 n n 11 1 x x be0 be1 bswp dbus7-0 dbus15-8 00 0 n n+1 01 0 n x 10 0 x n 11 0 x x 00 1 n+1 n 01 1 x n 10 1 n x 11 1 x x be0 be1 bswp dbus7-0 dbus15-8 xx 0 read data read data xx 1 read data read data be0 be1 bswp dbus7-0 dbus15-8 xx 0 write data x xx 1 x write data
am79c940 33 tdtreq would remain de-asserted. hence for byte wide data transfers, the xmtfw should be pro- grammed to the 8 or 16 write cycle limit, or the host should ensure that sufficient data will be written to the xmtfifo after tdtreq has been de-asserted (which is permitted), to guarantee that the transmission will commence. a third alternative is to program the trans- mit start point (xmtsp) in the biu configuration con- trol register to below the 64-byte default; thereby imposing a lower latency to the host system requiring additional data to ensure the xmtfifo does not underflow during the transmit process, versus using the default xmtsp value. note that if 64 single byte writes are executed on the xmtfifo, and the xmtsp is set to 64-bytes, the transmission will commence, and all 64-bytes of information will be accepted by the xmtfifo. the number of write cycles that the host uses to write the packet into the transmit fifo will also directly in- fluence the amount of space utilized by the transmit message. if the number of write cycles (n) required to transfer a packet to the transmit fifo is even, the number of bytes used in the transmit fifo will be 2*n. if the number of write cycles required to transfer a packet to the transmit fifo is odd, the number of bytes used in the transmit fifo will be 2*n + 2 be- cause the end of frame indication in the xmtfifo is always placed at the end of a 4-byte boundary. for ex- ample, a 32-byte message written as bytes (n = 32 cy- cles) will use 64-bytes of space in the transmit fifo (2*n = 64), whereas a 65-byte message written as 32 words and 1 byte (n = 33 cycles) would use 68-bytes (2*n + 2 = 68) . the transmit fifo has been sized appropriately to minimize the system interface overhead. however, consideration must be given to overall system design if byte writes are supported. in order to guarantee that sufficient space is present in the xmtfifo to accept the number of write cycles programmed by the xmtfw (including an end of frame delimiter), tdtreq may go inactive before the xmtsp threshold is reached when using the non burst mode (xmtbrst = 0). for instance, assume that the xmtfw is programmed to allow 32 write cycles (default), and xmtsp is pro- grammed to require 64 bytes (default) before starting transmission. assuming that the host bursts the trans- mit data in a 32 cycle block, writing a single byte any- where within this block will mean that xmtsp will not have been reached. this would be a typical scenario if the transmit data buffer was not aligned to a word boundary. the mace device will continue to assert tdtreq since an additional 36 write cycles can still be executed. if the host starts a second burst, the xmtsp will be reached, and tdtreq will deassert when less that 32 write cycle can be performed although the data written by the host will continue to be accepted. the host must be aware that additional space exists in the xmtfifo although tdtreq becomes inactive, and must continue to write data to ensure the xmtsp threshold is achieved. no transmit activity will com- mence until the xmtsp threshold is reached. once 36 write cycles have been executed. note that write cycles can be performed to the xmt- fifo even if the tdtreq is inactive. when tdtreq is asserted, it guarantees that a minimum amount of space exists, when tdtreq is deasserted, it does not necessarily indicate that there is no space in the xmt- fifo. the dtv pin will indicate the successful accep- tance of data by the transmit fifo. as another example, assume again that the xmtfw is programmed for 32 write cycles. if the host writes word wide data continuously to the xmtfifo, the tdtreq will deassert when 36 writes have executed on the xmtfifo, at which point 72-bytes will have been writ- ten to the xmtfifo, the 64-byte xmtsp will have been exceeded and the transmission of preamble will have commenced. tdtreq will not re-assert until the transmission of the packet data has commenced and the possibility of losing data due to a collision within the slot time is removed (512 bits have been transmitted without a collision indication). assuming that the host actually stopped writing data after the initial 72-bytes, there will be only 16-bytes of data remaining in the xmtfifo (8-bytes of preamble/sfd plus 56-bytes of data have been transmitted), corresponding to 12.8 s of latency before an xmtfifo underrun occurs. this latency is considerably less than the maximum possi- ble 57.6 s the system may have assumed. if the host had continued with the block transfer until 64 write cycles had been performed, 128-bytes would have been written to the xmtfifo, and 72-bytes of latency would remain (57.6 s) when tdtreq was re-as- serted. transmit fifo ? burst operation the xmtfifo burst mode, programmed by the xmt- brst bit in the fifo configuration control register, modifies tdtreq behavior. the assertion of tdtreq is controlled by the programming of the xmtfw bits, such that when the specified number of write cycles can be guaranteed (8, 16 or 32), tdtreq will be as- serted. tdtreq will be de-asserted when the xmt fifo can only accept a single write cycle (one word write including an end of frame delimiter) allow- ing the external device to burst data into the xmtfifo when tdtreq is asserted, and stop when tdtreq is deasserted. receive fifo ? general operation the receive fifo contains additional logic to ensure that sufficient data is present in the rcvfifo to allow the specified number of bytes to be read, regardless of the ordering of byte/word read accesses. this has an
34 am79c940 impact on the perceived latency that the receive fifo provides to the host system. the description and table below outline the point at which rdtreq will be asserted when the first duration of the packet has been received and when any subsequent transfer of the packet to the host system is required. no preamble/sfd bytes are loaded into the receive fifo. all references to bytes pass through the receive fifo. these references are received after the pream- ble/sfd sequence. the first assertion of rdtreq for a packet will occur after the longer of the following two conditions is met: 64-bytes have been received (to assure runt pack- ets and packets experiencing collision within the slot time will be rejected). the rcvfw threshold is reached plus an additional 12 bytes. the additional 12 bytes are necessary to ensure that any permutation of byte/word read access is guaranteed. they are required for all threshold values, but in the case of the 16 and 32-byte thresholds, the requirement that the slot time criteria is met dominates. any subsequent assertion of rdtreq necessary to complete the transfer of the packet will occur after the rcvfw threshold is reached plus an additional 12 bytes. the table below also outlines the latency provided by the mace de- vice when the rdtreq is asserted. receive fifo watermarks, rdtreq assertion and latency receive fifo ? burst operation the rcvfifo also provides a burst mode capability, programmed by the rcvbrst bit in the fifo config- uration control register, to modify the operation of rdtreq .the assertion of rdtreq will occur accord- ing to the programming of the rcvfw bits. rdtreq will be de-asserted when the rcvfifo can only pro- vide a single read cycle (one word read). this allows the external device to burst data from the rcvfifo once rdtreq is asserted, and stop when rdtreq is deasserted. receive fifo ? low latency receive operation the low latency receive mode can be programmed using the low latency receive bit (llrcv in the receive frame control register). this effectively causes the assertion of rdtreq to be directly coupled to the low watermark of 12 bytes in the rcvfifo. once the 12-byte threshold is reached (plus some internal synchronization delay of less than 1 byte), rdtreq will be asserted, and will remain active until the rcvfifo can support only one read cycle (one word of data), as in the burst operation described earlier. the exception is the case where 4-8 bytes of padding is required by the fifo design, unless it is the end of the packet. the intended use for the low latency receive mode is to allow fast forwarding of a received packet in a bridge application. in this case, the receiving process is made aware of the receive packet after only 9.6 s, instead of waiting up to 60.8 s (76-bytes) necessary for the initial assertion of rdtreq . an ethernet-to-ethernet bridge employing the mace device (on all the ethernet connections) with the xmtsp of all mace controller xmt fifos set to the minimum (4-bytes), forwarding of a receive packet can be achieved within a sub 20 s delay including processing overhead. note, however, that this mode places significant bur- den on the host processor. the receiving mace device will no longer delete runt packets. a runt packet will have the receive frame status appended to the re- ceive data which the host must read as normal. the mace device will not attempt to delete runt packets from the rcvfifo in the low latency receive mode. collision fragments will also be passed to the host if they are detected after the 12-byte threshold has been reached. if a collision occurs, the receive frame sta- tus (rcvfs) will be appended to the data successfully received in the rcvfifo up to the point the collision was detected. no additional receive data will be written to the rcvfifo. note that the rcvfs will not become available until after the receive activity ceases. the col- lision indication (clsn) in the receive status (rcvsts) will be set, and the receive message byte count (rcvcnt) will be the correct count of the total duration of activity, including the period that collision was detected. the detection of normal (slot time) colli- sions versus late collisions can only be made by counting the number of bytes that were successfully re- ceived prior to the termination of the packet data. in all cases where the reception ends prematurely (runt or collision), the data that was successfully received rcvfw [1-0] bytes required for first assertion of rdtreq bytes of latency after first assertion of rdtreq bytes required for subsequent assertion of rdtreq bytes of latency after subsequent assertion of rdtreq 00 64 64 28 100 01 64 64 44 84 10 76 52 76 52 11 xx xx xx xx
am79c940 35 prior to the termination of reception must be read from the rcvfifo before the rcvfs bytes are available. media access control (mac) the media access control engine is the heart of the mace device, incorporating the essential protocol requirements for operation of a compliant ethernet/ 802.3 node, and providing the interface between the fifo sub-system and the manchester encoder/ decoder (mendec). the mac engine is fully compliant to section 4 of iso/ iec 8802-3 (ansi/ieee standard 1990 second edi- tion) and ansi/ieee 802.3 (1985). the mac engine provides enhanced features, pro- grammed through the transmit frame control and receive frame control registers, designed to minimize host supervision and pre or post message processing. these features include the ability to disable retries after a collision, dynamic fcs generation on a packet-by-packet basis, and automatic pad field insertion and deletion to enforce minimum frame size attributes. the two primary attributes of the mac engine are: transmit and receive message data encapsulation ? framing (frame boundary delimitation, frame synchronization) ? addressing (source and destination address handling) ? error detection (physical medium transmission errors) media access management ? medium allocation (collision avoidance) ? contention resolution (collision handling) transmit and receive message data encapsulation data passed to the mace device transmit fifo will be assumed to be correctly formatted for transmission over the network as a valid packet. the user is required to pass the data stream for transmission to the mace chip in the correct order, according to the byte ordering convention programmed for the biu. the mace device provides minimum frame size enforcement for transmit and receive packets. when apad xmt = 1 (default), transmit messages will be padded with sufficient bytes (containing 00h) to ensure that the receiving station will observe an information field (destination address, source address, length/type, data and fcs) of 64-bytes. when astrp rcv = 1 (default), the receiver will automatically strip pad and fcs bytes from the received message if the value in the length field is below the minimum data size (46-bytes). both features can be independently over-ridden to allow illegally short (less than 64-bytes of packet data) messages to be transmitted and/or received. framing (frame boundary delimitation, frame synchronization) the mace device will autonomously handle the con- struction of the transmit frame. when the transmit fifo has been filled to the predetermined threshold (set by xmtsp), and providing access to the channel is currently permitted, the mace device will commence the 7 byte preamble sequence (10101010b, where first bit transmitted is a 1). the mace device will subse- quently append the start frame delimiter (sfd) byte (10101011) followed by the serialized data from the transmit fifo. once the data has been completed, the mace device will append the fcs (most significant bit first) computed on the entire data portion of the message. note that the user is responsible for the correct order- ing and content in each of the fields in the frame, including the destination address, source address, length/type and packet data. the receive section of the mace device will detect an incoming preamble sequence and lock to the encoded clock. the internal mendec will decode the serial bit stream and present this to the mac engine. the mac will discard the first 8-bits of information before search- ing for the sfd sequence. once the sfd is detected, all subsequent bits are treated as part of the frame. the mace device will inspect the length field to ensure minimum frame size, strip unnecessary pad characters (if enabled), and pass the remaining bytes through the receive fifo to the host. if pad stripping is performed, the mace device will also strip the received fcs bytes, although the normal fcs computation and checking will occur. note that apart from pad stripping, the frame will be passed unmodified to the host. if the length field has a value of 46 or greater, the mace de- vice will not attempt to validate the length against the number of bytes contained in the message. if the frame terminates or suffers a collision before 64-bytes of information (after sfd) have been received, the mace device will automatically delete the frame from the receive fifo, without host inter- vention. note however, that if the low latency receive option has been enabled (llrcv = 1 in the receive frame control register), the mace device will not delete receive frames which experience a collision once the 12-byte low watermark has been reached (see the fifo sub-system section for additional details). addressing (source and destination address handling) the first 6-bytes of information after sfd will be inter- preted as the destination address field. the mace device provides facilities for physical, logical and
36 am79c940 broadcast address reception. in addition, multiple physical addresses can be constructed (perfect address filtering) using external logic in conjunction with the eadi interface. error detection (physical medium transmission errors) the mace device provides several facilities which report and recover from errors on the medium. in addi- tion, the network is protected from gross errors due to inability of the host to keep pace with the mace device activity. on completion of transmission, the mace device will report the transmit frame status for the frame. the exact number of transmission retry attempts is reported (one, more used with xmtrc, or rtry), and whether the mace device had to defer (defer) due to channel activity. in addition, loss of carrier is reported, indicating that there was an interruption in the ability of the mace device to monitor its own transmis- sion. repeated lcar errors indicate a potentially faulty transceiver or network connection. excessive defer (exdef) will be reported in the transmit retry count register if the transmit frame had to wait for an abnormally long period before transmission. additional transmit error conditions are reported through the interrupt register. the late collision (lcol) error indicates that the transmission suffered a collision after the slot time. this is indicative of a badly configured network. late collisions should not occur in normal operating net- work. the collision error (cerr) indicates that the trans- ceiver did not respond with an sqe test message within the predetermined time after a transmission completed. this may be due to a failed transceiver, disconnected or faulty transceiver drop cable, or the fact the transceiver does not support this feature (or it is disabled). in addition to the reporting of network errors, the mace device will also attempt to prevent the creation of any network error caused by inability of the host to service the mace device. during transmission, if the host fails to keep the transmit fifo filled sufficiently, causing an underflow, the mace device will guarantee the message is either sent as a runt packet (which will be deleted by the receiving station) or has an invalid fcs (which will also allow the receiving station to reject the message). the status of each receive message is passed via the receive frame status bytes. fcs and framing errors (fram) are reported, although the received frame is still passed to the host. the fram error will only be reported if an fcs error is detected and there are a non integral number of bytes in the message. the mace device will ignore up to seven additional bits at the end of a message (dribbling bits), which can occur under normal network operating conditions. the reception of eight additional bits will cause the mace device to de-serialize the entire byte, and will result in the received message and fcs being modified. received messages which suffer a collision after 64-byte times (after sfd) will be marked to indicate they have suffered a late collision (clsn). additional counters are provided to report the receive collision count and runt packet count to be used for network statistics and utilization calculations. note that if the mace device detects a received packet which has a 00b pattern in the preamble (after the first 8-bits which are ignored), the entire packet will be ignored. the mace device will wait for the network to go inactive before attempting to receive additional frames. media access management the basic requirement for all stations on the network is to provide fairness of channel allocation. the 802.3/ ethernet protocols define a media access mechanism which permits all stations to access the channel with equality. any node can attempt to contend for the chan- nel by waiting for a predetermined time (inter packet gap interval) after the last activity, before transmitting on the media. the channel is a bus or multidrop com- munications medium (with various topological configu- rations permitted) which allows a single station to transmit and all other stations to receive. if two nodes simultaneously contend for the channel, their signals will interact causing loss of data, defined as a collision. it is the responsibility of the mac to attempt to avoid and recover from a collision, to guarantee data integrity for the end-to-end transmission to the receiving station. medium allocation (collision avoidance) the ieee 802.3 standard (iso/iec 8802-3 1990) requires that the csma/cd mac monitors the medium for traffic by watching for carrier activity. when carrier is detected, the media is considered busy, and the mac should defer to the existing message. the ieee 802.3 standard also allows optional two part deferral after a receive message. see ansi/ieee std 802.3-1990 edition, 4.2.3.2.1: note: ? it is possible for the pls carrier sense indica- tion to fail to be asserted during a collision on the media. if the deference process simply times the inter- frame gap based on this indication it is possible for a short interframe gap to be generated, leading to a potential reception failure of a subsequent frame. to enhance system robustness the following optional measures, as specified in 4.2.8, are recommended when interframespacing part1 is other than zero: ?
am79c940 37 (1) upon completing a transmission, start timing the interpacket gap, as soon as transmitting and carrier sense are both false. (2) when timing an interframe gap following reception, reset the interframe gap timing if carriersense becomes true during the first 2/3 of the interframe gap timing interval. during the final 1/3 of the interval the timer shall not be reset to ensure fair access to the medium. an initial period shorter than 2/ 3 of the interval is permissible including zero. ? the mac engine implements the optional receive two part deferral algorithm, with a first part in- ter-frame-spacing time of 6.0 s. the second part of the inter-frame-spacing interval is therefore 3.6 s. the mace device will perform the two part deferral algorithm as specified in section 4.2.8 (process defer- ence). the inter packet gap (ipg) timer will start timing the 9.6 s interframespacing after the receive carrier is de-asserted. during the first part deferral (interframespacingpart1-ifs1) the mace device will defer any pending transmit frame and respond to the receive message. the ipg counter will be reset to zero continuously until the carrier deasserts, at which point the ipg counter will resume the 9.6 s count once again. once the ifs1 period of 6.0 s has elapsed, the mace device will begin timing the second part deferral (interframespacingpart2-ifs2) of 3.6 s. once ifs1 has completed, and ifs2 has commenced, the mace chip will not defer to a receive packet if a transmit packet is pending. this means that the mace device will not attempt to receive an incoming packet, and it will start to transmit at 9.6 s regardless of network activity, forcing a collision if an existing transmission is in progress. the mace device will guarantee to com- plete the preamble (64-bit) and jam (32-bit) sequence before ceasing transmission and invoking the random backoff algorithm. in addition to the deferral after receive process, the mace device also allows transmit two part deferral to be implemented as an option. the option can be dis- abled using the dxmt2pd bit in the mac configura- tion control register. two part deferral after transmission is useful for ensuring that severe ipg shrinkage cannot occur in specific circumstances, causing a transmit message to follow a receive mes- sage so closely, as to make them indistinguishable. during the time period immediately after a transmission has been completed, the external transceiver (in the case of a standard aui connected device), should gen- erate the sqe test message (a nominal 10 mhz burst of 5-15 bt duration) on the ci pair (within 0.6-1.6 s after the transmission ceases). during the time period in which the sqe test message is expected the mace device will not respond to receive carrier sense. see ans t42i/ieee std 802.3-1990 edition, 7.2.4.6 (1)): ? at the conclusion of the output function, the dte opens a time window during which it expects to see the signal_quality_error signal asserted on the control in circuit. the time window begins when the carrier_status becomes carrier_off. if execution of the output function does not cause carrier_on to occur, no sqe test occurs in the dte. the duration of the window shall be at least 4.0 s but no more than 8.0 s. during the time win- dow the carrier sense function is inhibited. ? the mace device implements a carrier sense blinding period within 0 s-4.0 s from deassertion of carrier sense after transmission. this effectively means that when transmit two part deferral is enabled (dxmt2pd in the mac configuration control register is cleared) the ifs1 time is from 4 s to 6 s after a transmission. however, since ipg shrinkage below 4 s will not be encountered on correctly configured networks, and since the fragment size will be larger than the 4 s blinding window, then the ipg counter will be reset by a worst case ipg shrinkage/fragment scenario and the mace device will defer its transmission. the mace chip will not restart the carrier sense blinding period if carrier is detected within the 4.0-6.0 s portion of ifs1, but will restart timing of the entire ifs1 period. contention resolution (collision handling) collision detection is performed and reported to the mac engine either by the integrated manchester encoder/decoder (mendec), or by use of an external function (e.g. serial interface adaptor, am7992b) utilizing the gpsi. if a collision is detected before the complete preamble/ sfd sequence has been transmitted, the mace de- vice will complete the preamble/sfd before appending the jam sequence. if a collision is detected after the preamble/sfd has been completed, but prior to 512 bits being transmitted, the mace device will abort the transmission, and append the jam sequence immedi- ately. the jam sequence is a 32-bit all zeroes pattern. the mace device will attempt to transmit a frame a total of 16 times (initial attempt plus 15 retries) due to normal collisions (those within the slot time). detection of collision will cause the transmission to be re-sched- uled, dependent on the backoff time that the mace de- vice computes. each collision which occurs during the transmission process will cause the value of xmtrc in the transmit retry count register to be updated. if a single retry was required, the one bit will be set in the transmit frame status. if more than one retry was re- quired, the more bit will be set, and the exact number of attempts can be determined (xmtrc+1). if all 16 at- tempts experienced collisions, the rtry bit will be set
38 am79c940 (one and more will be clear), and the transmit mes- sage will be flushed from the xmtfifo, either by reset- ting the xmtfifo (if no end-of-frame tag exists) or by moving the xmtfifo read pointer to the next free lo- cation (if an end-of-frame tag is present). if retries have been disabled by setting the drtry bit, the mace device will abandon transmission of the frame on detection of the first collision. in this case, only the rtry bit will be set and the transmit message will be flushed from the xmtfifo. the rtry condition will cause the de-assertion of tdtreq , and the assertion of the intr pin, providing the xmtintm bit is cleared. if a collision is detected after 512 bit times have been transmitted, the collision is termed a late collision. the mace device will abort the transmission, append the jam sequence and set the lcol bit in the transmit frame status. no retry attempt will be scheduled on detection of a late collision, and the xmtfifo will be flushed. the late collision condition will cause the de-assertion of tdtreq , and the assertion of the intr pin, providing the xmtintm bit is cleared. the ieee 802.3 standard requires use of a truncated binary exponential backoff algorithm which provides a controlled pseudo random mechanism to enforce the collision backoff interval, before re-transmission is attempted. see ansi/ieee std 802.3-1990 edition, 4.2.3.2.5: ? at the end of enforcing a collision (jamming), the csma/cd sublayer delays before attempt- ing to re-transmit the frame. the delay is an in- teger multiple of slottime. the number of slot times to delay before the nth re-transmission attempt is chosen as a uniformly distributed random integer r in the range: 0 r 2 k , where k = min (n,10). ? the mace device implements a random number generator, configured to ensure that nodes experiencing a collision, will not have their retry inter- vals track identically, causing retry errors. the mace device provides an alternative algorithm, which suspends the counting of the slot time/ipg dur- ing the time that receive carrier sense is detected. this aids in networks where large numbers of nodes are present, and numerous nodes can be in collision. it effectively accelerates the increase in the backoff time in busy networks, and allows nodes not involved in the collision to access the channel whilst the colliding nodes await a reduction in channel activity. once chan- nel activity is reduced, the nodes resolving the collision time-out their slot time counters as normal. if a receive message suffers a collision, it will be either a runt, in which case it will be deleted in the receive fifo, or it will be marked as a receive late collision, using the clsn bit in the receive frame status regis- ter. all frames which suffer a collision within the slot time will be deleted in the receive fifo without requesting host intervention, providing that the llrcv bit (receive frame control) is not set. runt packets which suffer a collision will be aborted regardless of the state of the rpa bit (user test register). if the collision commences after the slot time, the mace device receiver will stop sending collided packet data to the receive fifo and the packet data read by the system will contain the amount of data received to the point of collision; the clsn bit in the receive frame status register will indicate the receive late collision. note that the receive message byte count will report the total number of bytes during the receive activity, including the collision. in all normal receive collision cases, the mace device eliminates the transfer of packet data across the host bus. in a receive late collision condition, the mace chip minimizes the amount transferred. these functions preserve bus bandwidth utilization. manchester encoder/decoder (mendec) the integrated manchester encoder/decoder provides the pls (physical signaling) functions required for a fully compliant ieee 802.3 station. the mendec block contains the aui, dai interfaces, and supports the 10base-t interface; all of which transfer data to appro- priate transceiver devices in manchester encoded for- mat. the mendec provides the encoding function for data to be transmitted on the network using the high accuracy on-board oscillator, driven by either the crys- tal oscillator or an external cmos level compatible clock generator. the mendec also provides the decoding function from data received from the network. the mendec contains a power on reset (por) circuit, which ensures that all analog portions of the mace device are forced into their correct state during power up, and prevents erroneous data transmission and/or reception during this time. external crystal characteristics when using a crystal to drive the oscillator, the follow- ing crystal specification should be used to ensure less than 0.5 ns jitter at do
am79c940 39 * requires trimming crystal spec; no trim is 50 ppm total external clock drive characteristics when driving the oscillator from an external clock source, xtal2 must be left floating (unconnected). an external clock having the following characteristics must be used to ensure less than 0.5 ns jitter at do . mendec transmit path the transmit section encodes separate clock and nrz data input signals into a standard manchester encoded serial bit stream. the transmit outputs (do ) are designed to operate into terminated transmission lines. when operating into a 78 ohm terminated transmission line, signaling meets the required output levels and skew for cheapernet, ethernet and ieee-802.3. transmitter timing and operation a 20 mhz fundamental mode crystal oscillator provides the basic timing reference for the sia portion of the mace device. it is divided by two, to create the internal transmit clock reference. both clocks are fed into the sia ? s manchester encoder to generate the transitions in the encoded data stream. the internal transmit clock is used by the sia to internally synchronize the internal transmit data (itxd) from the controller and internal transmit enable (itena). the internal transmit clock is also used as a stable bit rate clock by the receive section of the sia and controller. the oscillator requires an external 0.005% crystal, or an external 0.01% cmos-level input as a reference. the accuracy requirements if an external crystal is used are tighter because allowance for the on-chip oscillator must be made to deliver a final accuracy of 0.01%. transmission is enabled by the controller. as long as the itena request remains active, the serial output of the controller will be manchester encoded and appear at do . when the internal request is dropped by the controller, the differential transmit outputs go to one of two idle states, dependent on tsel in the mode register (csr15, bit 9): receive path the principal functions of the receiver are to signal the mace device that there is information on the receive pair, and separate the incoming manchester encoded data stream into clock and nrz data. the receiver section (see receiver block diagram) consists of two parallel paths. the receive data path is a zero threshold, wide bandwidth line receiver. the carrier path is an offset threshold bandpass detecting line receiver. both receivers share common bias net- works to allow operation over a wide input common mode range. parameter min nom max units 1. parallel resonant frequency 20 mhz 2. resonant frequency error (cl = 20 pf) ? 50 +50 ppm 3. change in resonant frequency with respect to temperature (cl = 20 pf)* ? 40 +40 ppm 4. crystal capacitance 20 pf 5. motional crystal capacitance (c1) 0.022 pf 6. series resistance 35 ohm 7. shunt capacitance 7pf clock frequency: 20 mhz 0.01% rise/fall time (tr/tf): < 6 ns from 0.5 v to v dd ? 0.5 xtal1 high/low time (thigh/tlow): 40 ? 60% duty cycle xtal1 falling edge to falling edge jitter: < 0.2 ns at 2.5 v input (v dd /2) tsel low: the idle state of do yields ? zero ? differential to operate transformer- coupled loads. tsel high: in this idle state, do+ is positive with respect to do ? (logical\high).
40 am79c940 input signal conditioning transient noise pulses at the input data stream are rejected by the noise rejection filter. pulse width rejection is proportional to transmit data rate. dc inputs more negative than minus 100 mv are also suppressed. the carrier detection circuitry detects the presence of an incoming data packet by discerning and rejecting noise from expected manchester data, and controls the stop and start of the phase-lock loop during clock acquisition. clock acquisition requires a valid manchester bit pattern of 1010 to lock onto the incoming message. when input amplitude and pulse width conditions are met at di , the internal enable signal from the sia to controller (rxcrs) is asserted and a clock acquisition cycle is initiated. clock acquisition when there is no activity at di (receiver is idle), the receive oscillator is phase locked to tck. the first neg- ative clock transition (bit cell center of first valid manchester ? 0") after rxcrs is asserted interrupts the receive oscillator. the oscillator is then restarted at the second manchester ? 0" (bit time 4) and is phase locked to it. as a result, the sia acquires the clock from the incoming manchester bit pattern in 4 bit times with a ? 1010" manchester bit pattern. srdclk and srd are enabled 1/4 bit time after clock acquisition in bit cell 5 if the enplsio bit is set in the pls configuration control register. srd is at a high state when the receiver is idle (no srdclk). srd however, is undefined when clock is acquired and may remain high or change to low state whenever srdclk is enabled. at 1/4 bit time through bit cell 5, the controller portion of the mace device sees the first srdclk transition. this also strobes in the incoming fifth bit to the sia as manchester ? 1". srd may make a transition after the srdclk rising edge bit cell 5, but its state is still undefined. the manchester ? 1" at bit 5 is clocked to srd output at 1/4 bit time in bit cell 6. pll tracking after clock acquisition, the phase-locked clock is com- pared to the incoming transition at the bit cell center (bcc) and the resulting phase error is applied to a correction circuit. this circuit ensures that the phase-locked clock remains locked on the received signal. individual bit cell phase corrections of the volt- age controlled oscillator (vco) are limited to 10% of the phase differencebetween bccand phase- locked clock. carrier tracking and end of message the carrier detection circuit monitors the di inputs after rxcrs is asserted for an end of message. rxcrs de-asserts 1 to 2 bit times after the last positive transition on the incoming message. this initiates the end of reception cycle. the time delay from the last ris- ing edge of the message to rxcrs deassert allows the last bit to be strobed by srdclk and transferred to the controller section, but prevents any extra bit(s) at the end of message. when irena de-asserts (see receive timing-end of reception (last bit = 0) and receive timing-end of reception (last bit = 1) wave- form diagrams) an rxcrs hold off timer inhibits rxcrs assertion for at least 2 bit times. data decoding the data receiver is a comparator with clocked output to minimize noise sensitivity to the di inputs. input error is less than 35 mv to minimize sensitivity to data receiver manchester decoder noise reject filter carrier detect circuit di srd srdclk rxcrs 16235d-5 receiver block diagram
am79c940 41 input rise and fall time. srdclk strobes the data receiver output at 1/4 bit time to determine the value of the manchester bit and clocks the data out on srd on the following srdclk. the data receiver also gener- ates the signal used for phase detector comparison to the internal sia voltage controlled oscillator (vco). differential input terminations the differential input for the manchester data (di ) is externally terminated by two 40.2 ohm 1% resistors and one optional common-mode bypass capacitor, as shown in the differential input termination diagram below. the differential input impedance, z idf , and the common-mode input impedance, z icm , are specified so that the ethernet specification for cable termination impedance is met using standard 1% resistor termina- tors. if sip devices are used, 39 ohms is also a suitable value. the ci differential inputs are terminated in exactly the same way as the di pair. collision detection a transceiver detects the collision condition on the net- work and generates a differential signal at the ci inputs. this collision signal passes through an input stage which detects signal levels and pulse duration. when the signal is detected by the mendec, it sets the clsn line high. the condition continues for ap- proximately 1.5 bit times after the last low-to-high transition on ci . jitter tolerance definition the receive timing-start of reception clock acquisi- tion waveform diagram shows the internal timing rela- tionships implemented for decoding manchester data in the sia module. the sia utilizes a clock capture circuit to align its internal data strobe with an incoming bit stream. the clock acquisition circuitry requires four valid bits with the values 1010. clock is phase locked to the negative transition at the bit cell center of the second ? 0" in the pattern. since data is strobed at 1/4 bit time, manchester tran- sitions which shift from their nominal placement through 1/4 bit time will result in improperly decoded data. with this as the criteria for an error, a definition of ? jitter handling ? is: the peak deviation approaching or crossing 1/4 bit cell position from nominal input transition, for which the sia section will properly decode data. attachment unit interface (aui) the aui is the pls (physical signaling) to pma (phys- ical medium attachment) interface which effectively connects the dte to the mau. the differential interface provided by the mace device is fully compliant to section 7 of iso 8802-3 (ansi/ieee 802.3). after the mace device initiates a transmission it will expect to see data looped-back on the di pair (aui port selected). this will internally generate a carrier sense , indicating that the integrity of the data path to and from the mau is intact, and that the mau is oper- ating correctly. this carrier sense signal must be asserted during the transmission when using the aui port (do transmitting). if carrier sense does not become active in response to the data transmission, or becomes inactive before the end of transmission, the loss of carrier (lcar) error bit will be set in the trans- curio di+ di 40.2 ? 40.2 ? 0.01 f aui isolation transformer 16235d-6 differential input termination
42 am79c940 mit frame status (bit 7) after the packet has been transmitted. digital attachment interface (dai) the digital attachment interface is a simplified electri- cal attachment specification which allows maus which do not require the dc isolation between the mau and dte (e.g. devices compatible with the 10base-t stan- dard and 10base-fl draft document) to be imple- mented. all data transferred across the dai port is manchester encoded. decoding and encoding is performed by the mendec. the dai port will accept receive data on the basis that the rxcrs input is active, and will take the data pre- sented on the rxdat input as valid manchester data. transmit data is sent to the external transceiver by the mace device asserting txen and presenting compli- mentary data on the txdat pair. during idle, the mace device will assert the txdat+ line high, and the txdat line low, while txen is maintained inactive (high). the mace device implements logical collision detection and will use the simultaneous assertion of txen and rxcrs to internally detect a collision con- dition, take appropriate internal action (such as abort the current transmit or receive activity), and provide external indication using the clsn pin. any external transceiver utilized for the dai interface must not loop back the transmit data (presented by the mace de- vice) on the txdat pins to the rxdat pin. neither should the transceiver assert the rxcrs pin when transmitting data to the network. duplication of these functions by the external transceiver (unless the mace device is in the external loop back test configuration) will cause false collision indications to be detected. in order to provide an integrity test of the connectivity between the mace device and the external transceiver similar to the sqe test message provided as a part of the aui functionality, the mace device can be pro- grammed to operate the dai port in an external loop- back test. in this case, the external transceiver is assumed to loopback the txdat data stream to the rxdat pin, and assert rxcrs in response to the txen request. when in the external loopback mode of operation (programmed by loop [1-0] = 01), the mace device will not internally detect a collision condi- tion. the external transceiver is assumed to take action to ensure that this test will not disrupt the network. this type of test is intended to be operated for a very limited period (e.g. after power up), since the transceiver is as- sumed to be located physically close to the mace device and with minimal risk of disconnection (e.g. con- nected via printed circuit board traces). note that when the dai port is selected, lcar errors will not occur, since the mace device will internally loop back the transmit data path to the receiver. this loop back function must not be duplicated by a transceiver which is externally connected via the dai port, since this will result in a condition where a collision is generated during any transmit activity. the transmit function of the dai port is protected by a jabber mechanism which will be invoked if the txdat and txen circuit is active for an excessive period (20 - 150 ms). this prevents a single node from disrupting the network due to a stuck-on or faulty transmitter. if this maximum transmit time is exceeded, the dai port transmitter circuitry is disabled, the clsn pin is asserted, the jabber bit (jab in the interrupt register) is set and the intr pin will be asserted providing the jabm bit (interrupt mask register) is cleared. once the internal transmit data stream from the mendec stops (txen deasserts), an unjab time of 250 ms-750 ms will elapse before the mace device deasserts the clsn indication and re-enables the transmit circuitry. when jabber is detected, the mace device will assert the clsn pin, de-assert the txen pin (regardless of internal mendec activity) and set the txdat+ and txdat pins to their inactive state. 10base-t interface twisted pair transmit function data transmission over the 10base-t medium requires use of the integrated 10base-t mau, and uses the differential driver circuitry in the txd and txp pins. the driver circuitry provides the necessary electrical driving capability and the pre-distortion con- trol for transmitting signals over maximum length twisted pair cable, as specified by the 10base-t supplement to the ieee 802.3 standard. the transmit function for data output meets the propagation delays and jitter specified by the standard. during normal transmission, and providing that the 10base-t mau is not in a link fail or jabber state, the txen pin will be driven high and can be used indirectly to drive a status led. twisted pair receive function the receiver complies with the receiver specifications of the ieee 802.3 10base-t standard, including noise immunity and received signal rejection criteria ( smart squelch ). signals meeting this criteria appearing at the rxd differential input pair are routed to the internal mendec. the receiver function meets the propaga- tion delays and jitter requirements specified by the 10base-t standard. the receiver squelch level drops to half its threshold value after unsquelch to allow reception of minimum amplitude signals and to mitigate carrier fade in the event of worst case signal attenua- tion and crosstalk noise conditions. during receive, the rxcrs pin is driven high and can be used indirectly to drive a status led. note that the 10base-t standard defines the receive input amplitude at the external media dependent interface
am79c940 43 (mdi). filter and transformer loss are not specified. the 10base-t mau receiver squelch levels are defined to ac- count for a 1db insertion loss at 10 mhz, which is typical for the type of receive filters/transformers recommended (see the appendix for additional details). normal 10base-t compatible receive thresholds are employed when the lrt bit is inactive (phy configu- ration control register). when the lrt bit is set, the low receive threshold option is invoked, and the sen- sitivity of the 10base-t mau receiver is increased. this allows longer line lengths to be employed, ex- ceeding the 100m target distance of normal 10base-t (assuming typical 24 awg cable). the additional cable distance attributes directly to increased signal attenua- tion and reduced signal amplitude at the 10base-t mau receiver. however, from a system perspective, making the receiver more sensitive means that it is also more susceptible to extraneous noise, primarily caused by coupling from co-resident services (crosstalk). for this reason, it is recommended that when using the low receive threshold option that the service should be installed on 4-pair cable only. multi-pair cables within the same outer sheath have lower crosstalk at- tenuation, and may allow noise emitted from adjacent pairs to couple into the receive pair, and be of sufficient amplitude to falsely unsquelch the 10base-t mau receiver. link test function the link test function is implemented as specified by 10base-t standard. during periods of transmit pair inactivity, link test pulses will be periodically sentover the twisted pair medium to constantly monitor medium integrity. when the link test function is enabled, the absence of link test pulses and receive data on the rxd pair will cause the 10base-t mau to go into a link fail state. in the link fail state, data transmission, data reception, data loopback and the collision detection functions are disabled, and remain disabled until valid data or >5 consecutive link pulses appear on the rxd pair. dur- ing link fail, the lnkst pin is inactive (externally pulled high), and the link fail bit (lnkfl in the phy configuration control register) will be set. when the link is identified as functional, the lnkst pin is driven low (capable of directly driving a link ok led using an integrated 12 ma driver) and the lnkfl bit will be cleared. in order to inter-operate with systems which do not implement link test, this function can be disabled by setting the the disable link test bit (dlnktst in the phy configuration control register). with link test disabled, the data driver, receiver and loopback func- tions as well as collision detection remain enabled irrespective of the presence or absence of data or link pulses on the rxd pair. the mace devices integrated 10base-t transceiver will mimic the performance of an externally connected device (such as a 10base-t mau connected using an aui). when the 10base-t transceiver is in link fail, the receive data path of the transceiver must be disabled. the mace device will report a loss of carrier error (lcar bit in the transmit frame status register) due to the absence of the normal loopback path, for every packet transmitted during the link fail condition. in ad- dition, a collision error (cerr bit in the transmit frame status register) will also be reported (see the section on signal quality error test function for additional details). if the awake bit is set in the phy configuration con- trol register prior to the assertion of the hardware sleep pin, the 10base-t receiver remains operable, and is able to detect and indicate (using the lnkst output) the presence of legitimate link test pulses or receive activity. the transmission of link test pulses is suspended to reduce power consumption. if the rwake bit is set in the phy configuration con- trol register prior to the assertion of the hardware sleep pin, the 10base-t receiver and transmitter functions remain active, the lnkst output is disabled, and the eadi output pins are enabled. in addition the aui port (transmit and receive) remains active. note that since the mac core will be in a sleep mode, no transmit activity is possible, and the transmission of link test pulses is also suspended to reduce power consumption. polarity detection and reversal the twisted pair receive function includes the ability to invert the polarity of the signals appearing at the rxd pair if the polarity of the received signal is reversed (such as in the case of a wiring error). this feature al- lows data packets received from a reverse wired rxd input pair to be corrected in the 10base-t mau prior to transfer to the mendec. the polarity detection func- tion is activated following reset or link fail, and will reverse the receive polarity based on both the polarity of any previous link test pulses and the polarity of subsequent packets with a valid end transmit delimiter (etd). when in the link fail state, the internal 10base-t receiver will recognize link test pulses of either posi- tive or negative polarity. exit from the link fail state is made due to the reception of five to six consecutive link test pulses of identical polarity. on entry to the link pass state, the polarity of the last five link test pulses is used to determine the initial receive polarity configuration and the receiver is reconfigured to subse- quently recognize only link test pulses of the previ- ously recognized polarity. this link pulse algorithm is employed only until etd polarity determination is made as described later inthis section.
44 am79c940 positive link test pulses are defined as received signal with a positive amplitude greater than 520 mv (lrt = low) with a pulse width of 60 ns-200 ns. this positive excursion may be followed by a negative excursion. this definition is consistent with the expected received signal at a correctly wired receiver, when a link test pulse which fits the template of figure 14-12 in the 10base-t standard is generated at a transmitter and passed through 100 m of twisted pair cable. negative link test pulses are defined as received sig- nals with a negative amplitude greater than 520 mv (lrt = low) with a pulse width of 60 ns-200 ns. this negative excursion may be followed by a positive ex- cursion. this definition is consistent with the expected received signal at a reverse wired receiver, when a link test pulse which fits the template of figure 14-12 in the 10base ? t standard is generated at a transmit- ter and passed through 100 m of twisted pair cable. the polarity detection/correction algorithm will remain armed until two consecutive packets with valid etd of identical polarity are detected. when armed, the receiver is capable of changing the initial or previous polarity configuration based on the most recent etd polarity. on receipt of the first packet with valid etd following reset or link fail, the mace device will utilize the inferred polarity information to configure its rxd input, regardless of its previous state. on receipt of a second packet with a valid etd with correct polarity, the detection/correction algorithm will lock-in the received polarity. if the second (or subsequent) packet is not detected as confirming the previous polarity decision, the most recently detected etd polarity will be used as the default. note that packets with invalid etd have no effect on updating the previous polarity decision. once two consecutive packets with valid etd have been received, the mace device will disable the detection/correction algorithm until either a link fail condition occurs or a hardware or software reset occurs. during polarity reversal, the rxpol pin should be externally pulled high and the reversed polarity bit (revpol in the phy configuration control register) will be set. during normal polarity conditions, the rxpol pin is driven low (capable of directly driving a polarity ok led using an integrated 12 ma driver) and the revpol bit will be cleared. if desired, the polarity correction function can be dis- abled by setting the disable auto polarity correction bit (dapc bit in the phy configuration control register). however, the polarity detection portion of the algorithm continues to operate independently, and the rxpol pin and the revpol bits will reflect the polarity state of the receiver. twisted pair interface status three outputs (txen, rxcrs and clsn) indicate whether the mace device is transmitting (mendecto twisted pair), receiving (twisted pair to mendec), or in a collision state with both functions active simultaneously. the mace device will power up in the link fail state. the normal algorithm will apply to allow it to enter the link pass state. on power up, the txen, rxcrs and clsn) pins will be in a high impedance state until they are enabled by setting the enable pls i/o bit (enplsio in the pls configuration control register) and the 10base-t port enters the link pass state. in the link pass state, transmit or receive activity which passes the pulse width/amplitude requirements of the do or rxd inputs, will be indicated by the txen or rxcrs pin respectively going active. txen, rxcrs and clsn are all asserted during a collision. in the link fail state, txen, rxcrs and clsn are inactive. in jabber detect mode, the mace device will activate the clsn pin, disable txen (regardless of manches- ter data output from the mendec), and allow the rxcrs pin to indicate the current state of the rxd pair. if there is no receive activity on rxd , only clsn will be active during jabber detect. if there is rxd ac- tivity, both clsn and rxcrs will be active. if the sleep pin is asserted (regardless of the pro- gramming of the awake or rwake bits in the phy configuration control register), the txen, rxcrs and clsn outputs will be placed in a high impedance state. collision detect function simultaneous activity (presence of valid data signals) from both the internal mendec transmit function (indi- cated externally by txen active) and the twisted pair rxd pins constitutes a collision, thereby causing an external indication on the clsn pin, and an internal indication which is returned to the mac core. the txen, rxcrs and clsn pins are driven high during collision. signal quality error (sqe) test (heartbeat) function the sqe test message (a 10 mhz burst normally returned on the aui ci pair at the end of every trans- mission) is intended to be a self-test indication to the dte that the mau collision circuitry is functional and the aui cable/connection is intact. this has minimal relevance when the 10base-t mau is embedded in the lan controller. a collision error (cerr bit in the in- terrupt register) will be reported only when the 10base-t port is in the link fail state, since the collision circuit of the mau will be disabled, causing the absence of the sqe test message. in gpsi mode the
am79c940 45 external encoder/decoder is responsible for asserting the clsn pin after each transmission. in dai mode, seq test has no relevance. jabber function the jabber function inhibits the twisted pair transmit function of the mace device if the txd /txp circuits are active for an excessive period (20-150 ms). this prevents any one node from disrupting the network due to a stuck-on or faulty transmitter. if this maximum transmit time is exceeded, the data path through the 10base-t transmitter circuitry is disabled (although link test pulses will continue to be sent), the clsn pin is asserted, the jabber bit (jab in the interrupt regis- ter) is set and the intr pin will be asserted providing the jabm bit (interrupt mask register) is cl eared. once the internal transmit data stream from the men- dec stops (txen deasserts), an unjab time of 250-750 ms will elapse before the mace device deasserts the clsn indication and re-enables the transmit circuitry. when jabber is detected, the mace device will assert the clsn pin, de-assert the txen pin (regardless of internal mendec activity), and allow the rxcrs pin to indicate the current state of the rxd pair. if there is no receive activity on rxd , only clsn will be active dur- ing jabber detect. if there is rxd activity, both clsn and rxcrs will be active. external address detection interface (eadi) this interface is provided to allow external perfect ad- dress filtering . this feature is typically utilized for termi- nal server, bridge and/or router type products. the use of external logic is required, to capture the serial bit stream from the mace device, and compare this with a table of stored addresses or identifiers. see the eadi port diagram in the systems applications section, network interfaces sub-section, for details. the eadi interface operates directly from the nrz decoded data and clock recovered by the manchester decoder. this allows the external address detection to be performed in parallel with frame reception and address comparison in the mac station address detection (sad) block. srdclk is provided to allow clocking of the receive bit stream from the mace device, into the external address detection logic. once a received packet com- mences and data and clock are available from the decoder, the eadi interface logic will monitor the alter- nating ( 1,0 ) preamble pattern until the two ones of the start frame delimiter ( 1,0,1,0,1,0,1,1 ) are detected, at which point the sf/bd output will be driven high. after sf/bd is asserted the serial data from srd should be de-serialized and sent to a content addressable memory (cam) or other address detection device. to allow simple serial to parallel conversion, sf/bd is provided as a strobe and/or marker to indicate the delineation of bytes, subsequent to the sfd. this fea- ture provides a mechanism to allow not only capture and/or decoding of the physical or logical (group) address, but also facilitates the capture of header information to determine protocol and or inter-network- ing information. the eam/r pin is driven by the exter- nal address comparison logic, to either reject or accept the packet. two alternative modes are permitted, al- lowing the external logic to either accept the packet based on address match, or reject the packet if there is no match. the two alternate methods are programmed using the match/reject (m/ r ) bit in the receive frame control register. if the m/r bit is set, the pin is configured as eam (external address match). the mace device can be configured with physical, logical or broadcast address comparison operational. if an internal address match is detected, the packet will be accepted regardless of the condition of eam . additional addresses can be located in the external address detection logic. if a match is detected, eam must go active within 600 ns of the last bit in the destination address field (end of byte 6) being presented on the srd output, to guarantee frame reception. in addition, eam must go inactive after a match has been detected on a previous packet, before the next match can take place on any subsequent packet. eam must be asserted for a minimum pulse width of 200 ns. if the m/r bit is clear (default state after either the reset pin or swrst bit have been activated), the pin is configured as ear (external address reject). the mace device can be configured with physical, logical or broadcast address comparison operational. if an internal address match is detected, the packet will be accepted regardless of the condition of ear . incoming packets which do not pass the internal address com- parison will continue to be received by the mace device. ear must be externally presented to the mace chip prior to the first assertion of rdtreq , to guarantee rejection of unwanted packets. this allows approximately 58 byte times after the last destination address bit is available to generate the ear signal, as- suming the mace device is not configured to accept runt packets. ear will be ignored by the mace device from 64 byte times after the sfd, and the packet will be accepted if ear has not been asserted before this time. if the mace device is configured to accept runt packets, the ear signal must be generated prior to the receive message completion, which could be as short as 12 byte times (assuming six bytes for source address, two bytes for length, no data, four bytes for fcs) after the last bit of the destination address is
46 am79c940 available. ear must have a pulse width of at least 200 ns. note that setting the prom bit (mac configuration control) will cause all receive packets to be received, regardless of the programming of m/r or the state of the eam/r input. the following table summarizes the operation of the eadi features. internal/external address recognition capabilities general purpose serial interface (gpsi) the gpsi port provides the signals necessary to present an interface consistent with the non encoded data functions observed to/from a lan controller such as the am7990 local area network controller for ethernet (lance). the actual gpsi pins are function- ally identical to some of the pins from the dai and the eadi ports, the gpsi replicates this type of interface. the gpsi allows use of an external manchester encoder/decoder, such as the am7992b serial inter- face adapter (sia). in addition, it allows the mace device to be used as a mac sublayer engine in a repeater based on the am79c980 integrated multiport repeater (imr). simple connection to the imr expan- sion bus allows the mac to view all packet data pass- ing through a number of interconnected imrs, allowing statistics and network management information to be collected. the gpsi functional pins are duplicated as follows: pin configuration for gpsi function ieee 1149.1 test access port interface an ieee 1149.1 compatible boundary scan test access port is provided for board level continuity test and diagnostics. all digital input, output and input/out- put and input/output pins are tested. analog pins, including the aui differential driver (do ) and receiv- ers di , ci ), and the crystal input (xtal1/xtal2) pins, are not tested. the following is a brief summary of the ieee 1149.1 compatible test functions implemented in the mace device. for additional details, consult the ieee stan- dard test access port and boundary-scan architec- ture document (ieee std 1149.1 ? 1990). the boundary scan test circuit requires four pins (tck, tms, tdi and tdo ), defined as the test access port (tap). it includes a finite state machine (fsm), an instruction register, a data register array and a power on reset circuit. internal pull-up resistors are provided for the tck, tdi and tms pins. the tap engine is a 16 state fsm, driven by the test clock (tck) and the test mode select (tms) pins. an independent power on reset circuit is provided to ensure the fsm is in the test_logic_reset state at power up. in addition to the minimum ieee 1149.1 instruction requirements (extest, sample and bypass), three additional instructions (idcode, tri_st and set_i/ o) are provided to further ease board level testing. all unused instruction codes are reserved. ieee 1149.1 supported instruction summary prom m/r eam/r required timing received messages 1 x x no timing requirements all received frames 0 0 h no timing requirements all received frames 00 low for 200 ns within 512-bits after sfd physical/logical/broadcast matches 0 1 h no timing requirements physical/logical/broadcast matches 01 low for 200 ns within 8-bits after da field all received frames function type lance pin mace pin receive data i rx rxdat receive clock i rclk srdclk receive carrier sense i rena rxcrs collision i clsn clsn transmit data o tx txdat+ transmit clock i tck stdclk transmit enable o tena txen inst ame description selected data reg reg mode inst code extest external test bsr test 0000 idcode id code inspection id reg normal 0001 sample sample boundary bsr normal 0010 tri_st force tristate bypass normal 0011 set_i/0 control boundaryto i/0 bypass test 0100 bypass bypass scan bypass normal 1111
am79c940 47 after hardware or software reset, the idcode instruc- tion is always invoked. the decoding logic provides signals to control the data flow in the data registers according to the current instruction. each boundary scan register (bsr) cell also has two stages. a flip-flop and a latch are used in the serial shift stage and the parallel output stage respectively. there are four possible operational modes in the bsr cell: 1. capture 2. shift 3. update 4. system function other data registers bypass reg (1 bit) device identification register (32 bits) bits 31-28:version (4 bits) bits 27-12:part number (16 bits) is 9400h bits 11-1:manufacturer id (11 bits). the manufacturer id code for amd is 00000000001 in accordance with jedec publication 106-a. bit 0:always a logic 1 slave access operation internal register accesses are based on a 2 or 3 sclk cycle duration, dependent on the state of the tc input pin. tc must be externally pulled low to force the mace device to perform a 3-cycle access. tc is inter- nally pulled high if left unconnected, to configure the 2-cycle access by default. all register accesses are byte wide with the exception of the data path to and from the internal fifos. data exchanges to/from register locations will take place over the appropriate half of the data bus to suit the host memory organization (as programmed by the bswp bit in the biu configuration control register). the be0 , be1 and eof signals are provided to allow control of the data flow to and from the fifos. byte read operations from the receive fifo cause data to be duplicated on both the upper and lower bytes of the data bus. byte write operations to the transmit fifo must use the be0 and be1 inputs to define the active data byte to the mace device. read access details of the read access timing are located in the ac waveforms section, host system interface, figures: two-cycle receive fifo/register read timing and three-cycle receive fifo/register read timing. tc can be dynamically changed on a cycle by cycle basis to program the slave cycle execution for two (tc = high) or three (tc = low) sclk cycles. tc must be stable by the falling edge of sclk (edsel = high) in s0 at the start of a cycle, and should only be changed in s0 in a multiple cycle burst. a read cycle is initiated when either cs or fds is sam- pled low on the falling edge of sclk at s0. fds and cs must be asserted exclusively. if they are active simultaneously when sampled, the mace device will not execute any read or write cycle. if cs is low, a register address read will take place. the state of the add4 ? 0 will be used to commence decoding of the appropriate internal register/fifo. if fds is low, a fifo direct read will take place from the rcvfifo. the state of the add4-0 bus is irrele- vant for the fifo direct mode. with either the cs or fds input active, the state of the add0-4 (for register address reads), r/w (high to indicate a read cycle), be0 and be1 will also be latched on the falling (edsel = high) edge of sclk at s0. from the falling edge of sclk in s1 (edsel = high), the mace device will drive data on dbus15-0 and activate the dtv output (providing the read cycle com- pleted successfully). if the cycle read the last byte/word of data for a specific frame from the rcvfifo, the mace device will also assert the eof signal. dbus15- 0, dtv and eof will be guaranteed valid and can be sampled on the falling (edsel = high) edge of sclk at s2. if the register address mode is being used to access the rcvfifo, once eof is asserted during the last byte/word read for the frame, the receive frame sta- tus can be read in one of two ways. the register ad- dress mode can be continued, by placing the appropriate address (00110b) on the address bus and executing four read cycles (cs active) on the receive frame status location. in this case, additional register address read requests from the rcvfifo will be ig- nored, and no dtv returned, until all four bytes of the receive frame status register have been read. alter- natively, a fifo direct read can be performed, which will effectively route the receive frame status through the rcvfifo location. this mechanism is explained in more detail below. if the fifo direct mode is used, the receive frame status can be read directly from the rcvfifo by con- tinuing to execute read cycles (by asserting fds low and r/w high) after eof is asserted indicating the last byte/word read for the frame. each of the four bytes of receive frame status will appear on both halves of the data bus, as if the actual receive frame status regis- ter were being accessed. alternatively, the status can be read as normal using the register address mode by
48 am79c940 placing the appropriate address (00110b) on the address bus and executing four read cycles (cs active). either the fifo direct or register address modes can be interleaved at any time to read the receive frame status, although this is considered unlikely due to the additional overhead it requires. in either case, no addi- tional data will be read from the rcvfifo until the receive frame status has been read, as four bytes appended to the end of the packet when using the fifo direct mode, or as four bytes from the receive frame status location when using the register address mode. eof will only be driven by the mace device when reading received packet data from the rcvfifo. at all other times, including reading the receive frame sta- tus using the fifo direct mode, the mace device will place eof in a high impedance state. rdtreq should be sampled on the falling edge of sclk. the assertion of rdtreq is programmed by rcvfw, and the de-assertion is modified dependent on the state of the rcvbrst bit (both in the fifo con- figuration control register). see the section receive fifo read for additional details. write access details of the write access timing are located in the ac waveforms section, host system interface, figures: two-cycle transmit fifo/register write timing and three-cycle transmit fifo/register write timing . write cycles are executed in a similar manner as the read cycle previously described, but with the r/w input low, and the host responsible to provide the data with sufficient set up to the falling edge of sclk after s2. after a fifo write, tdtreq should be sampled on or after the falling (edsel = high) edge of sclk after s3 of the fifo write. the state of tdtreq at this time will reflect the state of the xmtfifo. after going active (low), tdtreq will remain low for two or more xmtfifo writes. the minimum high (inactive) time of tdtreq is one sclk cycle. when eof is written to the transmit fifo, tdtreq will go inactive after one sclk cycle, for a minimum of one sclk cycle. initialization after power-up, reset should be asserted for a mini- mum of 15 sclk cycles to set the mace device into a defined state. this will set all mace registers to their default values. the receive and transmit functions will be turned off. a typical sequence to initialize the mace device could look like this: write the biu configuration control (biucc) regis- ter to change the byte swap mode to big endian or to change the transmit start point. write the fifo configuration control (fifocc) register to change the fifo watermarks or to enable the fifo burst mode. write the interrupt mask register (imr) to disable unwanted interrupt sources. write the pls configuration control (plscc) register to enable the active network port. if the gpsi interface is used, the register must be written twice. the first write access should only set portsel [1 ? 0] = 11. the second access must write again portsel[1 ? 0] = 11 and additionally set enplsio = 1. this sequence is required to avoid contention on the clock, data and/or carrier indica- tion signals. write the phy configuration control (phycc) reg- ister to configure any non-default mode if the 10base-t interface is used. program the logical address filter (ladrf) regis- ter or the physical address register (padr). the internal address configuration (iac) register must be accessed first. set the address change (addrchg) bit to request access to the internal address ram. poll the bit until it is cleared by the mace device indicating that access to the internal address ram is permitted. in the case of an address ram access after hardware or software reset (enrcv has not been set), the mace device will return addrchg = 0 right away. set the logaddr bit in the iac register to select writing to the logical address filter register. set the phy- addr bit in the iac register to select writing to the physical address register. either bit can be set to- gether with writing the addrchg bit. initializing the logical address filter register requires 8 write cycles. initializing the physical address register requires 6 write cycles. write the user test register (utr) to set the mace device into any of the user diagnostic modes such as loopback. write the mac configuration control (maccc) reg- ister as the last step in the initialization sequence to enable the receiver and transmitter. note that the system must guarantee a delay of 1 ms after power-up before enabling the receiver and transmit- ter to allow the mace phase lock loop to stabilize. the transmit frame control (xmtfc) and the receive frame control (rcvfc) registers can be programmed on a per packet basis.
am79c940 49 reinitialization the swrst bit in the biu configuration control (biucc) register can be set to reset the mace device into a defined state for reinitialization. the same sequence described in the initialization section can be used. the 1 ms delay for the mace phase lock loop stabilization need not to be observed as it only applies to a power-up situation. transmit operation the transmit operation and features of the mace device are controlled by programmable options. these options are programmed through the biu, fifo and mac configuration control registers. parameters controlled by the mac configuration con- trol register are generally programmed only once, during initialization, and are therefore static during the normal operation of the mace device (see the media access control section for a detailed description). the features controlled by the fifo configuration control register and the transmit frame control register can be re-programmed if the mace device is not transmit- ting. transmit fifo write the transmit fifo is accessed by performing a host generated write sequence on the mace device. see the slave access operation-write access section and the ac waveforms section, host system interface, fig- ures: two-cycle transmit fifo/register write timing and three-cycle transmit fifo/register write timing for details of the write access timing. there are two fundamentally different access methods to write data into the fifo. using the register address mode, the fifo can be addressed using the add0-4 lines, (address 00001b), initiating the cycle with the cs and r/w (low) signals. the fifo direct mode allows write access to the transmit fifo without use of the address lines, and using only the fds and r/w lines. if the mace device detects both signals active, it will not execute a write cycle. the write cycle timing for the register address or direct fifo modes are identical. fds and cs should be mutually exclusive. the data stream to the transmit fifo is written using multiple byte and/or word writes. cs or fds does not have to be returned inactive to commence execution of the next write cycle. if cs /fds is detected low at the falling edge of s0, a write cycle will commence. note that eof must be asserted by the host/controller during the last byte/word transfer. transmit function programming the transmit frame control register allows program- ming of dynamic transmit attributes. automatic transmit features such as retry on collision, fcs generation/ transmission and pad field insertion can all be programmed, to provide flexibility in the (re-)transmission of messages. the disable retry on collision (drtry bit) and auto- matic pad field insertion (apad xmt bit) features should not be changed while data remains in the trans- mit fifo. writing to either the drtry or apad xmt bits in this case may have unpredictable results. these bits are not internally latched or protected. when writ- ing to the transmit frame control register the drtry and apad xmt bits should be programmed consis- tently. once the transmit fifo is empty, drtry and apad xmt can be reprogrammed. this can be achieved with no risk of transmit data loss or corruption by clearing enxmt after the packet data for the current frame has been completely loaded. the transmission will complete normally and the activation of the intr pin can be used to determine if the transmit frame has completed (xmtint will be set in the inter- rupt register). once the transmit frame status has been read, apad xmt and/or drtry can be changed and enxmt set to restart the transmit process with the new parameters. apad xmt is sampled if there are less than 60 bytes in the transmit packet when the last bit of the last byte is transmitted. if apad xmt is set, a pad field of pattern 00h is added until the minimum frame size of 64 bytes (excluding preamble and sfd) is achieved. if apad xmt is clear, no pad field insertion will take place and runt packet transmission is possible. when apad xmt is enabled, the dxmtfcs feature is over-ridden and the four byte fcs will be added to the transmitted packet unconditionally. the disable fcs generation/transmission feature can be programmed dynamically on a packet by packet basis. the current state of the dxmtfcs bit is internally latched on the last write to the transmit fifo, when the eof indication is asserted by the host/controller. the programming of static transmit attributes are dis- tributed between the biu, fifo and mac configura- tion control registers. the point at which transmission begins in relation to the number of bytes of a frame in the fifo is controlled by the xmtsp bits in the biu configuration control register. depending on the bus latency of the system, xmtsp can be set to ensure that the transmit fifo does not underflow before more data is written to the fifo. when the entire frame is in the fifo, or the fifo becomes full before the threshold is reached, transmis- sion of preamble will commence regardless of the value in xmtsp. the default value of xmtsp is 64 bytes after reset. the point at which tdtreq is asserted in relation to the number of empty bytes present in the transmit
50 am79c940 fifo is controlled by the xmtfw bits in the fifo con- figuration control register. tdtreq will be asserted when one of the following conditions is true: the number of bytes free in the transmit fifo rel- ative to the current saved read pointer value is greater than or equal to the threshold set by the xmtfw (16, 32 or 64 bytes). the saved read pointer is the first byte of the current transmit frame, either in progress or awaiting channel availability. the number of bytes free in the transmit fifo rel- ative to the current read pointer value is greater than or equal to the threshold set by the xmtfw (16, 32 or 64 bytes). the read pointer becomes available only after a minimum of 64 byte frame length has been transmitted on the network (eight bytes of preamble plus 56 bytes of data), and points to the current byte of the frame being transmitted. depending on the bus latency of the system, xmtfw can be set to ensure that the transmit fifo does not underflow before more data is written into the fifo. when the entire frame is in the fifo, tdtreq will remain asserted if sufficient bytes remain empty. the default value of xmtfw is 64 bytes after hardware or software reset. note that if the xmtfw is set below the 64 byte limit, the transmit latency for the host to service the mace device is effectively increased, since tdtreq will occur earlier in the transmit sequence and more bytes will be present in the transmit fifo when the tdtreq is de-asserted. the transmit operation of the mace device can be halted at any time by clearing the enxmt bit (bit 1) in the mac configuration control register. note that any complete transmit frame that is in the transmit fifo and is currently in progress will complete, prior to the transmit function halting. transmit frames in the fifo which have not commenced will not be started. trans- mit frames which have commenced but which have not been fully transferred into the transmit fifo will be aborted, in one of two ways. if less than 544 bits (68 bytes) have been transmitted onto the network, the transmission will be terminated immediately, generat- ing a runt packet which can be deleted at the receiving station. if greater than 544 bits have been transmitted, the messages will have the current crc inverted and appended at the next byte boundary, to guarantee an error is detected at the receiving station. this feature ensures that packets will not be generated with poten- tial undetected data corruption. an explanation of the 544 bit derivation appears in the ? automatic pad generation ? section. automatic pad generation transmit frames can be automatically padded to ex- tend them to 64 data bytes (excluding preamble) per- mitting the minimum frame size of 64 bytes (512 bits) for 802.3/ethernet to be guaranteed, with no software intervention from the host system. apad xmt = 1 enables the automatic padding feature. the pad is placed between the llc data field and fcs field in the 802.3 frame. the fcs is always added if apad xmt = 1, regardless of the state of dxmtfcs. the transmit frame will be padded by bytes with the value of 00h. the default value of apad xmt will enable auto pad generation after hardware or software reset. it is the responsibility of upper layer software to cor- rectly define the actual length field contained in the message to correspond to the total number of llc data bytes encapsulated in the packet (length field as defined in the ieee 802.3 standard). the length value contained in the message is not used by the mace device to compute the actual number of pad bytes to be inserted. the mace chip will append pad bytes depen- dent on the actual number of bits transmitted onto the network. once the last data byte of the frame has com- pleted, prior to appending the fcs, the mace device will check to ensure that 544 bits have been transmit- ted. if not, pad bytes are added to extend the frame size to this value, and the fcs is then added. the 544 bit count is derived from the following: preamble 1010....1010 sfd 10101011 dest addr srce addr length llc data pad fcs 56 bits 8 bits 6 bytes 6 bytes 2 bytes 4 bytes 46 ? 1500 bytes ieee 802.3 format data frame 16235d-7
am79c940 51 minimum frame size (excluding preamble, including fcs) 64 bytes 512 bits preamble/sfd size 8 bytes 64 bits fcs size 4 bytes 32bits to be classed as a minimum size frame at the receiver, the transmitted frame must contain: preamble + (min frame size + fcs) bits at the point that fcs is to be appended, the transmitted frame should contain: preamble + (min frame size ? fcs) bits 64 + (512 ? 32) bits a minimum length transmit frame from the mace device will therefore be 576 bits, after the fcs is appended. the ethernet specification makes no use of the llc pad field, and assumes that minimum length messages will be at least 64 bytes in length. transmit fcs generation automatic generation and transmission of fcs for a transmit frame depends on the value of dxmtfcs (disable transmit fcs) when the eof is asserted indi- cating the last byte/word of data for the transmit frame is being written to the fifo. the action of writing the last data byte/word of the transmit frame, latches the current contents of the transmit frame control regis- ter, and therefore determines the programming of dxmtfcs for the transmit frame. when dxmtfcs = 0 the transmitter will generate and append the fcs to the transmitted frame. if the automatic padding feature is invoked (apad xmt in transmit frame control), the fcs will be appended regardless of the state of dxmt- fcs. note that the calculated fcs is transmitted most significant bit first. the default value of dxmtfcs is 0 after hardware or software reset. transmit status information although multiple transmit frames can be queued in the transmit fifo, the mace device will not permit loss of transmit frame status information. the transmit frame status and transmit retry count can only be buffered internally for a maximum of two frames. the mace device will therefore not commence a third transmit frame, until the status from the first frame is read. once the transmit retry count and transmit frame status for the first transmit packet is read, the mace device will autonomously begin the next trans- mit frame, provided that a transmit frame is pending, the xmtsp threshold has been exceeded (or the xmt fifo is full), the network medium is free, and the ipg time has elapsed. indication of valid transmit frame status can be obtained by servicing the hardware interrupt and test- ing the xmtint bit in the interrupt register, or by poll- ing the xmtsv bit in the poll register if a continuous polling mechanism is required. if the transmit retry count data is required (for loading, diagnostic, or man- agement information), xmtrc must be read prior to xmtfs. reading the xmtfs register when the xmtsv bit is set will clear both the xmtrc and xmtfs values. transmit exception conditions exception conditions for frame transmission fall into two distinct categories; those which are the result of normal network operation and those which occur due to abnormal network and/or host related events. normal events which may occur and which are handled autonomously by the mace device are: (a) collisions within the slot time with automatic retry (b) deletion of packets due to excessive transmis- sion attempts. (a) the mace device will ensure that collisions which occur within 512 bit times from the start of transmission (including preamble) will be automatically retried with no host intervention. the transmit fifo ensures this by guaranteeing that data contained within the trans- preamble 1010....1010 synch 11 dest addr srce addr type data fcs 62 bits 2 bits 6 bytes 6 bytes 2 bytes 4 bytes 46 ? 1500 bytes 16235d-8 ethernet format data frame
52 am79c940 mit fifo will not be overwritten until at least 64 bytes (512 bits) of data have been successfully transmitted onto the network. this criteria will be met, regardless of whether the transmit frame was the first (or only) frame in the transmit fifo, or if the transmit frame was queued pending completion of the preceding frame. (b) if 16 total attempts (initial attempt plus 15 retries) have been made to transmit the frame, the mace device will abandon the transmit process for the partic- ular frame, de-assert the tdtreq pin, report a retry error (rtry) in the transmit frame status, and set the xmtint bit in the interrupt register, causing activation of the external intr pin providing the interrupt is unmasked. once the xmtint condition has been externally recog- nized, the transmit frame counter (xmtfc) can be read to determine whether the tail end of the frame that suffers the rtry error is still in the host memory (i.e., when xmtfc = 0). this xmtfc read should be requested before the transmit frame status read since reading the xmtfs would cause the xmtfc to decrement. if the tail end of the frame is indeed still in the host memory, the host is responsible for ensuring that the tail end of the frame does not get written into the fifo and does not get transmitted as a whole frame. it is recommended that the host clear the tail end of the frame from the host memory before request- ing the xmtfs read so that after the xmtfs read, when mace device re-asserts tdtreq , the tail end of the frame does not get written into the fifo. the transmit frame status read will indicate that the rtry error occurred. the read operation on the transmit frame status will update the fifo read and write pointers. if no end-of-frame write (eof pin assertion) had occurred during the fifo write sequence, the en- tire transmit path will be reset (which will update the transmit fifo watermark with the current xmtfw value in the fifo configuration control register). if a whole frame does reside in the fifo, the read pointer will be moved to the start of the next frame or free loca- tion in the fifo, and the write pointer will be unaf- fected. tdtreq will not be re-asserted until the transmit frame status has been read. after a rtry error, all further packet transmission will be suspended until the transmit frame status is read, regardless of whether additional packet data exists in the fifo to be transmitted. receive fifo read opera- tions are not impaired. packets experiencing 16 unsuccessful attempt to transmit will not be re-tried. recovery from this condi- tion must be performed by upper layer software. abnormal network conditions include: (a) loss of carrier. (b) late collision. (c) sqe test error. these should not occur on a correctly configured 802.3 network, but will be reported if the network has been incorrectly configured or a fault condition exists. (a) a loss of carrier condition will be reported if the mace device cannot observe receive activity while it is transmitting. after the mace device initiates a trans- mission it will expect to see data looped-back on the receive input path. this will internally generate a carrier sense, indicating that the integrity of the data path to and from the external mau is intact, and that the mau is operating correctly. when the aui port is selected, if carrier sense does not become active in response to the data transmission, or becomes inactive before the end of transmission, the loss of carrier (lcar) error bit will be set in the trans- mit frame status (bit 7) after the packet has been transmitted. the packet will not be re-tried on the basis of an lcar error. when the 10base ? t port is selected, lcar will be reported for every packet transmitted during the link fail condition. when the gpsi port is selected, lcar will be reported if the rxcrs input pin fails to become active during a transmission, or once active, goes inactive before the end of transmission. when the dai port is selected, lcar errors will not occur, since the mace device will internally loop back the transmit data path to the receiver. the loop back feature must not be performed by the external trans- ceiver when the dai port is used. during internal loopback, lcar will not be set, since the mace device has direct control of the transmit and receive path integrity. when in external loopback, lcar will operate normally according to the specific port which has been selected. (b) a late collision will be reported if a collision condition exists or commences 64 byte times (512 bit times) after the transmit process was initiated (first bit of preamble commenced). the mace device will abandon the transmit process for the particular frame, complete transmission of the jam sequence (32-bit all zeroes pattern), de-assert the tdtreq pin, report the late collision (lcol) and transmit status valid (xmtsv) in the transmit frame status, and set the xmtint bit in the interrupt register, causing activation of the external intr pin providing the interrupt is unmasked. once the xmtint condition has been externally recog- nized, the transmit frame counter (xmtfc) can be read to determine whether the tail end of the frame that suffers the lcol error is still in the host memory (i.e., when xmtfc = 0). this xmtfc read should be requested before the transmit frame status read since reading the xmtfs would cause the xmtfc to decrement. if the tail end of the frame is indeed still in
am79c940 53 the host memory, the host is responsible for ensuring that the tail end of the frame does not get written into the fifo and does not get transmitted as a whole frame. it is recommended that the host clear the tail end of the frame from the host memory before request- ing the xmtfs read so that after the xmtfs read,when the mace device re-asserts tdtreq , the tail end of the frame does not get written into the fifo. the transmit frame status read will indicate that the lcol error occurred. the read operation on the trans- mit frame status will update the fifo read and write pointers. if no end-of-frame write (eof pin assertion) had occurred during the fifo write sequence, the en- tire transmit path will be reset (which will update the transmit fifo watermark with the current xmtfw value in the fifo configuration control register). if a whole frame resides in the fifo, the read pointer will be moved to the start of the next frame or free location in the fifo, and the write pointer will be unaffected. tdtreq will not be re-asserted until the transmit frame status has been read. after an lcol error, all further packet transmission will be suspended until the transmit frame status is read, regardless of whether additional packet data exists in the fifo to be transmitted. receive fifo operations are unaffected. packets experiencing a late collision will not be re-tried. recovery from this condition must be performed by upper layer software. (c) during the inter packet gap time following the com- pletion of a transmitted message, the aui ci pair is asserted by some transceivers as a self-test. when the aui port has been selected, the integral manchester encoder/decoder will expect the sqe test message (nominal 10 mhz sequence) to be returned via the ci pair, within a 40 network bit time period after di goes inactive. if the ci input is not asserted within the 40 network bit time period following the completion of transmission, then the mace device will set the cerr bit (bit 5) in the interrupt register. the intr pin will be activated if the corresponding mask bit cerrm = 0. when the gpsi port is selected, the mace device will expect the clsn input pin to be asserted 40 bit times after the transmission has completed (after txen out- put pin has gone inactive). when the dai port has been selected, the cerr bit will not be reported. a transceiver connected via the dai port is not expected to support the sqe test message feature. host related transmit exception conditions include: (a) overflow caused by excessive writes to the transmit fifo (dtv will not be issued if the trans- mit fifo is full). (b) underflow caused by lack of host writes to the transmit fifo. (c) not reading current transmit frame status. (a) the host may continue to write to the transmit fifo after the tdtreq has been de-asserted, and can safely do so on the basis of knowledge of the number of free bytes remaining (set by xmtfw in the fifo configuration control register). if however the host system continues to write data to the point that no ad- ditional fifo space exists, the mace device will not return the dtv signal and hence will effectively not acknowledge acceptance of the data. it is the host ? s responsibility to ensure that the data is re-presented at a future time when space exists in the transmit fifo, and to track the actual data written into the fifo. (b) if the host fails to respond to the tdtreq from the mace device before the transmit fifo is emptied, a fifo underrun will occur. the mace device will in this case terminate the network transmission in an orderly sequence. if less than 512 bits have been transmitted onto the network the transmission will be terminated immediately, generating a runt packet. if greater than 512 bits have been transmitted, the message will have the current crc inverted and appended at the next byte boundary, to guarantee an fcs error is detected at the receiving station. the mace device will report this condition to the host by de-asserting the tdtreq pin, setting the uflo and xmtsv bits (in the transmit frame status) and the xmtint bit (in the interrupt register), and asserting the intr pin providing the cor- responding xmtintm bit (in the interrupt mask regis ter) is cleared. once the xmtint condition has been externally recog- nized, the transmit frame counter (xmtfc) can be read to determine whether the tail end of the frame that suffers the uflo error is still in the host memory (i.e., when xmtfc = 0). in the case of fifo underrun, this will definitely be the case and the host is responsible for ensuring that the tail end of the frame does not get writ- ten into the fifo and does not get transmitted as a whole frame. it is recommended that the host clear the tail end of the frame from the host memory before requesting the xmtfs read so that after the xmtfs read, when the mace device re-asserts tdtreq , the tail end of the frame does not get written into the fifo. the transmit frame status read will indicate that the uflo error occurred. the read operation on the trans- mit frame status will update the fifo read and write pointers and the entire transmit path will be reset (which will update the transmit fifo watermark with the current xmtfw value in the fifo configuration control register). tdtreq will not be re-asserted until the transmit frame status has been read. (c) the mace device will internally store the transmit frame status for up to two packets. if the host fails to read the transmit frame status and both internal entries become occupied, the mace device will not commence any subsequent transmit frames to prevent overwriting of the internally stored values. this will
54 am79c940 occur regardless of the number of bytes written to the transmit fifo. receive operation the receive operation and features of the mace de- vice are controlled by programmable options. these options are programmed through the biu, fifo and mac configuration control registers. parameters controlled by the mac configuration con- trol register are generally programmed only once, dur- ing initialization, and are therefore static during the normal operation of the mace device (see the media access control section for a detailed description). the features controlled by the fifo configuration control register and the receive frame control register can be programmed without performing a reset on the part. the host is responsible for ensuring that no data is present in the receive fifo when re-programming the receive attributes. receive fifo read the receive fifo is accessed by performing a host generated read sequence on the mace device. see the slave access operation-read access section and the ac waveforms section, host system interface, fig- ures: ? 2 cycle receive fifo/register read timing ? and ? 3 cycle receive fifo/register read timing ? for details of the read access timing. note that eof will be asserted by the mace device during the last data byte/word transfer. receive function programming the receive frame control register allows program- ming of the automatic pad field stripping feature and the configuration of the match/reject (m/r) pin. astrp rcv and m/r must be static when the receive function is enabled (enrcv = 1). the receiver should be disabled before (re-) programming these options. the eadi port can be used to permit reception of frames to commence whilst external address decoding takes place. the m/r bit defines the function of the eam/r pin, and hence whether frames will be accepted or rejected by the external address comparison logic. the programming of additional receive attributes are distributed between the fifo and mac configuration control registers, and the user test register. all receive frames can be accepted by setting the prom bit (bit 7) in the mac configuration control reg- ister. when prom is set, the mace device will attempt to receive all messages, subject to minimum frame enforcement. setting prom will override the use of the eadi port to force the rejection of unwanted messages. see the sections external address detection interface for more details. the point at which rdtreq is asserted in relation to the number of bytes of a frame that are present in the receive fifo (rcvfifo) is controlled by the rcvfw bits in the fifo configuration control register, or the llrcv bit in the receive frame control register. rdtreq will be asserted when one of the following conditions is true: (i) there are at least 64 bytes in the rcvfifo. (ii) the received packet has passed the 64 byte mini- mum criteria, and the number of bytes in the rcvfifo is greater than or equal to the threshold set by the rcvfw (16 or 32 bytes). (iii) a receive packet has completed, and part or all of it is present in the rcvfifo. (iv) the llrcv bit has been set and greater than 12-bytes of at least 8 bytes have been received. note that if the rcvfw is set below the 64-byte limit, the mace device will still require 64-bytes of data to be received before the initial assertion of rdtreq . sub- sequently, rdtreq will be asserted at any time the rcvfw threshold is exceeded. the only times that the rdtreq will be asserted when there are not at least an initial 64-bytes of data in the rcvfifo are: (i) when the astrp rcv bit has been set in the re- ceive frame control register, and the pad is auto- matically stripped from a minimum length packet. (ii) when the rpa bit has been set in the user test register, and a runt packet of at least 8 bytes has been received. (iii) when the llrcv bit has been set in the receive frame control register, and at least 12-bytes (after sfd) has been received. no preamble/sfd bytes are loaded into the receive fifo. all references to bytes past through the receive fifo are received after the preamble/sfd sequence. depending on the bus latency of the system, rcvfw can be set to ensure that the rcvfifo does not over- flow before more data is read. when the entire frame is in the rcvfifo, rdtreq will be asserted regardless of the value in rcvfw. the default value of rcvfw is 64-bytes after hardware or software reset. the receive operation of the mace device can be halted at any time by clearing the enrcv bit in the mac configuration control register. note that any receive frame currently in progress will be accepted normally, and the mace device will disable the receive process once the message has completed. the missed packet count (mpc) will be incremented for
am79c940 55 subsequent packets that would have normally been passed to the host, and are now ignored due to the disabled state of the receiver. note that clearing the enrcv bit disables the asser- tion of rdtreq . if enrcv is cleared during receive activity and remains cleared for a long time and if the tail end of the receive frame currently in progress is longer than the amount of space available in the receive fifo, receive fifo overflow will occur. how- ever, even with rdtreq deasserted, if there is valid data in the receive fifo to be read, successful slave reads to the receive fifo can be executed (indicated by valid dtv ). it is the host ? s responsibility to avoid the overflow situation. automatic pad stripping during reception of a frame, the pad field can be stripped automatically. astrp rcv = 1 enables the automatic pad stripping feature. the pad field will be stripped before the frame is passed to the fifo, thus preserving fifo space for additional frames. the fcs field will also be stripped, since it is computed at the transmitting station based on the data and pad field characters, and will be invalid for a receive frame that has the pad characters stripped. the number of bytes to be stripped is calculated from the embedded length field (as defined in the ieee 802.3 definition) contained in the packet. the length indicates the actual number of llc data bytes con- tained in the message. any received frame which con- tains a length field less than 46 bytes will have the pad field stripped. receive frames which have a length field of 46 bytes or greater will be passed to the host unmodified. since any valid ethernet type field value will always be greater than a normal 802.3 length field, the mace device will not attempt to strip valid ethernet frames. note that for some network protocols, the value passed in the ethernet type and/or 802.3 length field is not compliant with either standard and may cause problems. the diagram below shows the byte/bit ordering of the received length field for an 802.3 compatible frame format. receive fcs checking reception and checking of the received fcs is per- formed automatically by the mace device. note that if the automatic pad stripping feature is enabled, the received fcs will be verified against the value computed for the incoming bit stream including pad characters, but it will not be passed through the re- ceive fifo to the host. if an fcs error is detected, this will be reported by the fcs bit (bit 4) in the receive frame status. receive status information the eof indication signals that the last byte/word of data has been passed from the fifo for the specific frame. this will be accompanied by a rcvint indica- tion in the the interrupt register signaling that the receive frame status has been updated, and must be preamble 1010....1010 synch 10101011 dest. addr. srce. addr. length llc data pad fcs 56 bits 8 bits 6 bytes 6 bytes 2 bytes 46 ? 1500 bytes 4 bytes most significant byte least significant byte bit 0 bit 7 start of packet at time= 0 increasing time bit 7 bit 0 45 ? 0 bytes 1 ? 1500 bytes 16235d-9 802.3 packet and length field transmission order
56 am79c940 read. the receive frame status is a single location which must be read four times to allow the four bytes of status information associated with each frame to be read. further data read operations from the receive fifo using the register address mode, will be ignored by the mace device (indicated by the mace chip not returning dtv ) until all four bytes of the receive frame status have been read. alternatively, the fifo direct access mode may be used to read the receive frame status through the receive fifo. in either case, the 4-byte total must be read before additional receive data can be read from the receive fifo. however, the rdtreq indication will continue to reflect the state of the receive fifo as normal, regardless of whether the receive frame status has been read. dtv will not be returned when a read operation is performed on the receive frame status location and no valid status is present or ready. note that the receive frame status can be read using either the register address or fifo direct modes. for additional details, see the section receive fifo read. receive exception conditions exception conditions for frame reception fall into two distinct categories; those which are the result of normal network operation, and those which occur due to abnormal network and/or host related events. normal events which may occur and which are handled autonomously by the mace device are basically colli- sions within the slot time and automatic runt packet deletion. the mace device will ensure that any receive packet which experiences a collision within 512 bit times from the start of reception (excluding preamble) will be automatically deleted from the receive fifo with no host intervention (the state of the rpa bit in the user test register; or the rcvfw bits in the fifo configuration control register have no effect on this). this criteria will be met, regardless of whether the receive frame was the first (or only) frame in the receive fifo, or if the receive frame was queued behind a previously received message. abnormal network conditions include: fcs errors framing errors dribbling bits late collision these should not occur on a correctly configured 802.3 network, but may be reported if the network has been incorrectly configured or a fault condition exists. host related receive exception conditions include: (a) underflow caused by excessive reads from the receive fifo (dtv will not be issued if the receive fifo is empty) (b) overflow caused by lack of host reads from the receive fifo (c) missed packets due to lack of host reads from the receive fifo and/or the receive frame status (a) successive read operations from the receive fifo after the final byte of data/status has been read, will cause the dtv pin to remain de-asserted during the read operation, indicating that no valid data is present. there will be no adverse effect on the receive fifo. (b) data present in the receive fifo from packets which completed before the overflow condition occurred, can be read out by accessing the receive fifo normally. once this data (and the associated receive frame status) has been read, the eof indica- tion will be asserted by the mace device during the first read operation takes place from the receive fifo, for the packet which suffered the overflow. if there were no other packets in the fifo when the overflow occurred, the eof will be asserted on the first read from the fifo. in either case, the eof indication will be accompanied by assertion of the intr pin, providing that the rcvintm bit in the interrupt mask register is not set. if the register address mode is being used, the host is required to access the receive frame status location using four separate read cycles. further access to the receive fifo will be ignored by the mace device until all four bytes of the receive frame status have been read. dtv will not be returned if a receive fifo read is attempted. if the fifo direct mode is being used, the host can read the receive frame status through the receive fifo, but the host must be aware that the subsequent four cycles will yield the receive status bytes, and not data from the same or a new packet. only the oflo bit will be valid in the receive frame status, other error/status and the rcvcnt fields are invalid. while the receive fifo is in the overflow condition, it is deaf to additional receive data on the network. how- ever, the mace device internal address detect logic continues to operate and counts the number of packets that would have been passed to the host under normal (non overflow) conditions. the missed packet count (mpc) is an 8-bit count (in register 24) that maintains the number of packets which pass the address match criteria, and complete without collision. the mpc counter will wrap around when the maximum count of 255 is reached, setting the mpco (missed packet count overflow) bit in the interrupt register, and asserting the intr pin providing that mpcom (missed packet count overflow mask) in the interrupt mask register is clear. mpco will be cleared (the interrupt will be unmasked) after hardware or software reset. however, until the first time that the receiver is enabled, mpc will not increment, hence no interrupt will occur due to missed packets after a reset.
am79c940 57 (c) failure to read packet data from the receive fifo will eventually cause an overflow condition. the fifo will maintain any previously completed packet(s), which can be read by the host at its convenience. however, packet data on the network will no longer be received, regardless of destination address, until the overflow is cleared by reading the remaining receive fifo data and receive status. the mace device will increment the missed packet count (mpc) register to indicate that a packet which would have been normally passed to the host, was dropped due to the error condition. note: the moment a packet overflow is detected or read, an eof with int is generated. on status read (oflow), the fifo pointers are reset to the first location. this essentially flushes the fifo. loopback operation during loopback, the fcs logic can be allocated to the receiver by setting rcvfcse = 1 in user test regis- ter. this permits both the transmit and receive fcs op- erations to be verified during the loopback process. the state of rcvfcse is only valid during loopback opera tion. if rcvfcse = 0, the mace device will calculate and append the fcs to the transmitted message. the receive message passed to the host will therefore con- tain an additional four bytes of fcs. the receive frame status will indicate the result of the loopback operation and the rcvcnt. if rcvfcse = 1, the last four bytes of the transmit message must contain the fcs computed for the transmit data preceding it. the mace device will trans- mit the data without addition of an fcs field, and the fcs will be calculated and verified at the receiver. the loopback facilities of the mace device allow full operation to be verified without disturbance to the net- work. loopback operation is also affected by the state of the loopback control bits (loop [0 ? 1]) in the user test register. this affects whether the internal men- dec is considered part of the internal or external loop-back path. when in the loopback mode(s), the multicast address detection feature of the mace device, programmed by the contents of the logical address filter (ladr [63 ? 0]) can only be tested when rcvfcse = 1, allocating the crc generator to the receiver. all other features operate identically in loopback as in normal operation, such as automatic transmit padding and receivepad stripping. user accessible registers the following registers are provided for operation of the mace device. all registers are 8-bits wide unless otherwise stated. note that all reserved register bits should be written as zero. receive fifo (rcvfifo) (reg addr 0) this register provides a 16-bit data path from the receive fifo. reading this register will read one word/ byte from the receive fifo. the rcvfifo should only be read when receive data transfer request (rdtreq ) is asserted. if the rcvfifo location is read before 64-bytes are available in the rcvfifo (or 12-bytes in the case that llrcv is set in the receive frame control register), dtv will not be returned. once the 64-byte threshold has been achieved and rdtreq is asserted, the de-assertion of rdtreq does not prevent additional data from being read from the rcvfifo, but indicates the number of additional bytes which are present, before the rcvfifo is emp- tied, and subsequent reads will not return dtv (see the fifo sub-system section for additional details). write operations to this register will be ignored and dtv will not be returned. byte transfers from the rcvfifo are supported, and will be fully aligned to the target memory architecture, defined by the bswp bit in the biu configuration con- trol register. the byte enable inputs (be1 -0) will define which half of the data bus should be used for the trans- fer. the external host/controller will be informed that the last byte/word of data in a receive frame is being read from the rcvfifo, when the mace device as- serts the eof signal. transmit fifo (xmtfifo) (reg addr 1) this register provides a 16-bit data path to the transmit fifo. byte/word data written to this register will be placed in the transmit fifo. the xmtfifo can be written at any time the transmit data transfer request (tdtreq ) is asserted. the de-assertion of tdtreq does not prevent data being written to the xmtfifo, but indicates the number of additional write cycles which can take place, before the xmtfifo is filled, and subsequent writes will not return dtv (see the fifo sub-system section for additional details). read oper- ations to this register will be ignored and dtv will not be returned. byte transfers to the xmtfifo are supported, and accept data from the source memory architecture to ensure the correct byte ordering for transmission, defined by the bswp bit in the mac configuration control register. the byte enable inputs (be1 -0) will define which half of the data bus should be used for the transfer. the use of byte transfers have implications on the latency time provided by the xmtfifo (see the fifo sub-system section for additional details). the external host/controller must indicate the last byte/word rcvfifo [15 ? 0] xmtfifo [15 ? 0]
58 am79c940 of data in a transmit frame is being written to the xmtfifo, by asserting the eof signal. transmit frame control (xmtfc) (reg addr 2) the transmit frame control register is latched inter- nally on the last write to the transmit fifo for each in- dividual packet, when eof is asserted. this permits automatic transmit padding and fcs generation on a packet-by-packet basis. bit name description bit 7 drtry disable retry. when drtry is set, the mace device will pro- vide a single transmission at- tempt for the packet, all further retries will be suspended. in the case of a collision during the at- tempt, a retry error (rtry) will be reported in the transmit sta- tus. with drtry cleared, the mace device will attempt up to 15 retries (16 attempts total) be- fore indicating a retry error. drtry is cleared by activation of the reset pin or swrst bit. drtry is sampled during the transmit process when a collision occurs. drtry should not be changed whilst data remains in the transmit fifo since this may cause an unpre- dictable retry response to a colli- sion. once the transmit fifo is empty, drtry can be repro- grammed. bit 6-4 res reserved. read as zeroes. always write as zeroes. bit 3 dxmtfcs disable transmit fcs. when dxmtfcs = 0 the transmitter will generate and append an fcs to the transmitted frame. when dxmtfcs = 1, no fcs will be appended to the transmit- ted frame, providing that apad xmt is also clear. if apad xmt is set, the calculated fcs will be appended to the transmitted message regardless of the state of dxmtfcs. the value of dxmtfcs for each frame is programmed when eof is as- serted to transfer the last byte/ word for the transmit packet to the fifo. dxmtfcs is cleared by activation of the reset pin or swrst bit. dxmtfcs is sampled only when eof is asserted during a transmit fifo write. bit name description bit 2-1 res reserved. read as zeroes. always write as zeroes. bit 0 apad xmt auto pad transmit. apad xmt enables the automatic padding feature. transmit frames will be padded to extend them to 64 bytes including fcs. the fcs is calculated for the entire frame including pad, and appended af- ter the pad field. apad xmt will override the programming of the dxmtfcs bit. apad xmt is set by activation of the reset pin or swrst bit. apad xmt is sampled only when eof is as- serted during a transmit fifo write. transmit frame status (xmtfs) (reg addr 3) the transmit frame status is valid when the xmtsv bit is set. the register is read only, and is cleared when xmtsv is set and a read operation is performed. the xmtint bit in the interrupt register will be set when any bit is set in this register. note that if xmtsv is not set, the values in this register can change at any time, including during a read opera- tion. this register should be read after the transmit retry count (xmtrc). see the description of the transmit retry count (xmtrc) for additional details. bit name description bit 7 xmtsv transmit status valid. transmit status valid indicates that this status is valid for the last frame transmitted. the value of xmtsv will not change during a read operation. bit 6 uflo underflow. indicates that the transmit fifo emptied before the end of frame was reached. the transmitted frame is truncat- ed at that point. if uflo is set, tdtreq will be de-asserted, and will not be re-asserted until the xmtfs has been read. bit 5 lcol late collision. indicates that a collision occurred after the slot time of the channel elapsed. if lcol is set, tdtreq will be de-asserted, and will not be drtry res res dxmtfcs res res apad xmt xmtsv uflo lcol more one defer lcar rtry
am79c940 59 re-asserted until the xmtfs has been read. the mace device does not retry after a late collision. bit 4 more more. indicates that more than one retry was needed to transmit the frame. one, more and rtry are mutually exclusive. bit 3 one one. indicates that exactly one retry was needed to transmit the frame. one, more and rtry are mutually exclusive. bit 2 defer defer. indicates that mace device had to defer transmission of the frame. this condition results if the channel is busy when the mace device is ready to transmit. bit 1 lcar loss of carrier. indicates that the carrier became false during a transmission. the mace device does not retry upon loss of carrier. lcar will not be set when the dai port is selected, when the 10base-t port is se- lected and in the link pass state, or during any internal loopback mode. when the 10base-t port is selected and in the link fail state, lcar will will be reported for any transmission attempt. bit 0 rtry retry error. indicates that all attempts to transmit the frame were unsuccessful, and that fur- ther attempts have been abort- ed. if disable retry (drtry in the transmit frame control reg- ister) is cleared, rtry will be set when a total of 16 unsuc- cessful attempts were made to transmit the frame. if drtry is set, rtry indicates that the first and only attempt to transmit the frame was unsuccessful. one, more and rtry are mutually exclusive. if rtry is set, tdtreq will be de-asserted, and will not be re-asserted until the xmtfs has been read. transmit retry count (xmtrc) (reg addr 4) the transmit retry count should be read only in response to a hardware interrupt request (intr asserted) when xmtint is set in the interrupt register, or after xmtsv is set in the poll register.the register should be read before the transmit frame status register. reading the transmit frame status with xmtsv set will cause the xmtrc value to be reset. this register is read only. bit name description bit 3-0 exdef excessive defer. the exdef bit will be set if a transmit frame waited for an excessive period for transmission. an excessive defer time is defined in accor- dance with the following (from page 34, section 5.2.4.1 of ieee std 802.3h-1990 layer manage- ment):maxdefertime = {2 x (max frame size x 8)} bits where maxframesize = 1518 bytes (from page 68, section 4.4.2.1 of ansi/ieee std 802.3-1990). so, the maxdefertime = 24288 bits = 2 14 + 2 12 + 2 11 + 2 10 + 2 9 +2 7 +2 6 +2 5 bit 6-4 res reserved. read as zeroes. always write as zeroes. bit 3-0 xmtrctransmit retry count. contains [3-0] the count of the number of retry attempts made by the mace device to transmit the current transmit packet. the value of the counter will be zero if the first transmission attempt was suc- cessful, and a maximum of 15 if all retry attempts were utilized. rtry will be set in transmit frame status if all 16 attempts were unsuccessful. receive frame control (rcvfc) (reg addr 5) bit name description bit 7-4 res reserved. read as zeroes. always write as zeroes. bit 3 llrcv low latency receive. a programmable option to allow access to the receive fifo before the 64-byte threshold has been reached. when set, data can be read from the rcvfifo once a low threshold (12-bytes after sfd plus synchronization) has been exceeded, causing rdtreq to be asserted. rdtreq will remain asserted as long as one read cycle can be performed on the rcvfifo (identical to the burst mode). indication of a valid read cycle from the rcvfifo will return dtv asserted. reading the rcvfifo before data is avail- able, or while waiting for addi- exdef res res res xmtrc[3-0] res res res res llrcv m/r res astrprcv
60 am79c940 tional data once a packet is in progress will not cause the rcvfifo to underflow, and will be indicated by dtv being invalid. the mace device will no longer be able to reject runts in this mode, this responsibility is transferred to the host system. in the case of a collided packet (normal slot time collision or late collision), the mace device will abort the reception, and return the rcvfs. note that all colli- sions in this mode will appear as late collisions and be reported by the clsn bit in the receive status (rcvsts) byte. if the host does not keep up with the incoming receive data, nor- mal rcvfifo overflow recovery is provided. bit 2 m/r match/reject. the match/reject option sets the criteria for the external address detection interface. if set, the eam/r pin is configured as external address match, and is used to signal the acceptance of a receive frame to the mace device. if cleared, the pin functions as external address reject and is used to flush unwanted packets from the receive fifo prior to the first assertion of rdtreq . m/r is cleared by activation of the reset pin or swrst bit. when the eadi feature is disabled, the eam/r pin must be tied active (low) and all normal receive ad- dress recognition configurations are supported (physical, logical and promiscuous). see the sec- tion ? external address detection interface ? for additional details. bit 1 res reserved. read as zero. always write as zero. bit 0 astrp rcv auto strip receive. astrp rcv enables the automatic pad stripping feature. the pad and fcs fields will be stripped from receive frames and not placed in the fifo. astrp rcv is set by activation of the reset pin or the swrst bit. receive frame status (rcvfs) (reg addr 6) the receive frame status is a single byte location which must be read by four read cycles to obtain the four bytes (32-bits) of status associated with each receive frame. receive frame status can be read using either the register direct or fifo direct access modes. in register direct mode, access to the receive fifo will be denied until all four status bytes for the com- pleted frame have been read from the receive frame status location. in fifo direct mode, the receive frame status is read through the receive fifo loca- tion, by continuing to execute four read cycles after the completion of packet data (and assertion of eof ). the receive frame status can be read using either mode, or a combination of both modes, however each status byte will be presented only once regardless of access method. other register reads and/or writes can be interleaved at any time, during the receive frame sta tus sequence. the receive frame status consists of the following four bytes of information: rfs0 receive message byte count (rcvcnt) [11 ? 0] rfs1 receive status, (rcvsts) [15 ? 12] rfs2 runt packet count (rntpc) [7 ? 0] rfs3 receive collision count (rcvcc) [7 ? 0] rfs0 ? receive message byte count (rcvcnt) bit name description bit 7-0 rcvcnt the receive message byte [7:0] count indicates the number of whole bytes in the received mes- sage. if pad bytes were stripped from the received frame, rcvcnt indicates the number of bytes received less the num- ber of pad bytes and less the number of fcs bytes. rcvcnt is 12 bits long. if a late collision is detected (clsn set in rcvsts), the count is an indi- cation of the length (in byte times) of the duration of the re- ceive activity including the colli- sion. rcvcnt [10:8] corre- spond to bits 3-0 in rfs1 of the receive frame status. rcvcnt [11 ? 0] will be invalid when oflo is set. rfs1 ? receive status (rcvsts) bit name description bit 7 oflo overflow flag. indicates that the receive fifo over flowed due rcvfs [31 ? 00] oflo clsn fram fcs rcvcnt [10:8] rcvcnt [7:0]
am79c940 61 to the inability of the host/con- troller to read data fast enough to keep pace with the receive se- rial bit stream and the latency provided by the receive fifo it- self. oflo is indicated on the re- ceive frame that caused the overflow condition; complete frames in the receive fifo are not affected. while the receive fifo is in the overflow condition, it ignores additional receive data on the network. the internal ad- dress detect logic will continue to operate and the missed pack- et count (mpc in register 24) will be incremented for each packet which passes the address match criteria, and complete without collision. bit 6 clsn collision flag. indicates that the receive operation suffered a col- lision during reception of the frame. if clsn is set, it indicates that the receive frame suffered a late collision, since a frame ex- periencing collision within the slot time will be automatically deleted from the rcvfifo (pro- viding llrcv in the receive frame control register is cleared). note that if the llrcv bit is enabled, the late collision threshold is effectively moved from the normal 64 ? byte (512 ? bit) level to the 12-byte (96 ? bit) level. runt packets suffering a collision will be flushed from the rcvfifo regardless of the state of the rpa bit (user test register). clsn will not be set if oflo is set. bit 5 fram framing error flag. indicates that the received frame contained a non-integer multiple of bytes and an fcs error. if there was no fcs error then fram will not be set. fram is not valid during internal loopback. fram will not be set if oflo is set. bit 4 fcs fcs error flag. indicates that there is an fcs error in the frame. the receive fcs is computed and checked normally when astrp rcv = 1, but is not passed to the host. fcs will not be set if oflo is set. bit 3-0 rcvcnt the receive message byte [11:8] count indicates the number of whole bytes in the received message from the network. rcvcnt is 12 bits long, and valid (accurate) only when there are no errors reported in the receive status (rcvsts). if a late collision is detected (clsn set in rcvsts), the count is an indication of the length (in byte times) of the duration of the receive activity including the collision. rcvcnt [7:0] corre- spond to bits 7-0 in rfs0 of the receive frame status. rcvcnt [11 ? 0} will be invalid when oflo is set. rfs2 ? runt packet count (rntpc) bit name description bit 7-0 rntpc the runt packet count indicates [7 ? 0] the number of runt packets received, addressed to this node, since the last successfully received packet. the value does not roll over after 255 runt packets have been detected, and will remain frozen at the maximum count. rfs3 ? receive collision count (rcvcc) bit name description bit 7 ? 0 rcvcc the receive collision count in- [7 ? 0] dicates the number of collisions detected on the network since the last successfully received packet. the value does not roll over after 255 collisions have been detected, and will remain frozen at the maximum count. fifo frame count (fifofc) (reg addr 7) bit name description bit 7 ? 4 rcvfc receive frame count. the (read [3 ? 0] only) count of the frames in the receive fifo. a frame is count- ed when the last byte is put in the fifo. the counter is decre- mented when the last byte of the frame is read. if the rcvfc reaches its maximum value of rntpc [7 ? 0] rcvcc [7 ? 0] rcvfc[3 ? 0] xmtfc[3 ? 0]
62 am79c940 15, additional receive frames will be ignored, and the missed packet count (mpc) register will be incremented for frames which match the internal address(es) of the mace device. bit 3 ? 0 xmtfc transmit frame count. the [3 ? 0] (read only) count of the frames in the transmit fifo. a frame is counted when the last byte is put in the fifo. the counter is dec- remented when xmtsv (in the transmit frame status and poll register) is set and the transmit frame status read access is performed. interrupt register (ir) (reg addr 8) all status bits are set upon occurrence of an event and cleared when read. the resister is read only. in addition all status bits are cleared by hardware or software reset. bit assignments for the register are as follows: bit name description bit 7 jab jabber error. jab indicates that the mace device attempted to transmit for an excessive time period (20 ? 150 ms), when using either the dai port or the 10base ? t port. if the internal jabber timer expires during transmission, the transmit bit stream will be interrupted, until the internal transmission ceases and the unjab timer (0.5 s 0.25 s) expires. the jabber function will be disabled, and jab will not be set, regardless of transmis- sion length, when either the aui or gpsi ports have been selected. jab is read/clear only, and is set by the mace device and reset when read. writing has no effect. it is also cleared by acti- vation of the reset pin or swrst bit. bit 6 babl babble error. babl is the transmitter time-out error. it in- dicates that the transmitter has been on the channel longer than the time required to send the maximum packet. it will be set after 1519 bytes (or great- er) have been transmitted. the mace device will continue to transmit until the current pack- et transmission is over. the intr pin will be activated if the corresponding mask bit bablm = 0. babl is read/clear only, and is set by the mace device and reset when read. writing has no effect. it is also cleared by activation of the reset pin or swrst bit. bit 5 cerr collision error. cerr indicates the absence of the signal quali- ty error test (sqe test) mes- sage after a packet transmis- sion. the sqe test message is a transceiver test feature. detec- tion depends on the mace net- work interface selected. in all cases, cerr will be set if the mace device failed to observe the sqe test message within 20 network bit times after the pack- et transmission ended. when cerr is set, the intr pin will be activated if the corresponding mask bit cerrm = 0. when the aui port is selected, the sqe test message is returned over the ci pair as a brief (5-15 bit times) burst of 10 mhz activity. when the 10base ? t port is selected, cerr will be reported after a transmission only when the internal transceiver is in the link fail state (lnkst pin = high). when the gpsi port is selected, the clsn pin must be asserted by the external encoder/decoder to provide the sqe test func- tion. when the dai port is select- ed, cerr will not be reported at any time. cerr is read/clear only. it is set by the mace and reset when read. writing has no effect. it is also cleared by activation of the reset pin or swrst bit. bit 4 rcvcco receive collision count over- flow. indicates that the receive collision count register rolled over at a value of 255 receive collisions. receive collisions are defined as received frames which suffered a collision. the intr pin will be activated if the corresponding mask bit rcvc- com = 0. note that the rcvcc value returned in the receive frame status (rfs3) will freeze at a value of 255, whereas this register based version of jab babl cerr rdvcco rntpco mpco rcvint xmtint
am79c940 63 rcvcc (reg addr 27) is free running. rcvcco is read/clear only. it is set by the mace device and reset when read. writing has no effect. it is also cleared by asserting the reset pin or swrst bit. bit 3 rntpco runt packet count overflow. indicates that the runt packet count register rolled over at a value of 255 runt packets. runt packets are defined as received frames which passed the inter- nal address match criteria but did not contain a minimum of 64-bytes of data after sfd. the intr pin will be activated if the corresponding mask bit rntpcom = 0. note that the rntpc value returned in the receive frame status (rfs2) will freeze at a value of 255, whereas this register based version of rntpc (reg addr 26) is free running. rntpco is read/clear only. it is set by the mace device and reset when read. writing has no effect. it is also cleared by asserting the reset pin or swrst bit. bit 2 mpco missed packet count overflow. indicates that the missed packet count register rolled over at a value of 255 missed frames. missed frames are defined as received frames which passed the internal address match criteria but were missed due to a receive fifo overflow, the receiver being disabled (enrcv = 0) or an excessive receive frame count (rcvfc > 15). the intr pin will be activated if the corresponding mask bit mpcom = 0. mpco is read/clear only. it is set by the mace device and reset when read. writing has no effect. it is also cleared by asserting the reset pin or swrst bit. bit 1 rcvint receive interrupt. indicates that the host read the last byte/word of a packet from the receive fifo. the receive frame sta- tus is available immediately on the next host read operation. the intr pin will be activated if the corresponding mask bit rcvintm = 0. rcvint is read/clear only. it is set by the mace device and reset when read. writing has no effect. it is also cleared by acti- vation of the reset pin or swrst bit. bit 0 xmtint transmit interrupt. indicates that the mace device has completed the transmission of a packet and updated the transmit frame status. the intr pin will be activated if the corresponding mask bit xmtintm = 0. xmtint is read/clear only. it is set by the mace device and reset when read. writing has no effect. it is also cleared by acti- vation of the reset pin or swrst bit. interrupt mask register (imr) (reg addr 9) this register contains the mask bits for the interrupts. read/write operations are permitted. writing a one into a bit will mask the corresponding interrupt. writing a zero to any previously set bit will unmask the corre- sponding interrupt. bit assignments for the register are as follows: bit name description bit 7 jabm jabber error mask. jabm is the mask for jab. the intr pin will not be asserted by the mace device regardless of the state of the jab bit, if jabm is set. it is cleared by activation of the reset pin or swrst bit. bit 6 bablm babble error mask. bablm is the mask for babl. the intr pin will not be asserted by the mace device regardless of the state of the babl bit, if bablm is set. it is cleared by activation of the reset pin or swrst bit. bit 5 cerrm collision error mask. cerrm is the mask for cerr. the intr pin will not be asserted by the mace device regardless of the state of the cerr bit, if cerrm is set. it is cleared by activation of the reset pin or swrst bit. bit 4 rcvccom receive collision count over- flow mask. rcvccom is the mask for rcvcco(receive collision count overflow). the intr pin will not be asserted by res bablm cerrm rcvccom rntpcom mpcom rcvintm xmtintm
64 am79c940 the mace device regardless of the state of the rcvcco bit, if rcvccom is set. it is cleared by activation of the reset pin or swrst bit. bit 3 rntpcom runt packet count overflow mask. rntpcom is the mask for rntpco (runt packet count overflow). the intr pin will not be asserted by the mace device regardless of the state of the rntpco bit, if rntpcom is set. it is cleared by activation of the reset pin or swrst bit. bit 2 mpcom missed packet count overflow mask. mpcom is the mask for mpco (missed packet count overflow). the intr pin will not be asserted by the mace device regardless of the state of the mpco bit, if mpcom is set. it is cleared by activation of the reset pin or swrst bit. bit 1 rcvintm receive interrupt mask. rcvintm is the mask for rcvint. the intr pin will not be asserted by the mace device regardless of the state of the rcvint bit, if rcvintm is set. it is cleared by activation of the reset pin or swrst bit. bit 0 xmtintm transmit interrupt mask. xmtintm is the mask for xmtint. the intr pin will not be asserted by the mace device regardless of the state of the xmtint bit, if xmtint is set. it is cleared by activation of the reset pin or swrst bit . poll register (pr) (reg addr 10) this register contains copies of internal status bits to simplify a host implementation which is non-interrupt driven. the register is read only, and its status is unaf- fected by read operations. all register bits are cleared by hardware or software reset. bit assignments are as follows: bit name description bit 7 xmtsv transmit status valid. transmit status valid indicates that the transmit frame status is valid. bit 6 tdtreq transmit data transfer request. an internal indication of the current request status of the transmit fifo. tdtreq is set when the external tdtreq signal is asserted. bit 5 rdtreq receive data transfer request. an internal indication of the cur- rent request status of the receive fifo. rdtreq is set when the external rdtreq signal is asserted. bit 4-0 res reserved. read as zeroes. always write as zeroes. biuconfigurationcontrol(biucc) (regaddr11) all bits within the biu configuration control register will be set to their default state upon a hardware or soft- ware reset. bit assignments are as follows: bit name description bit 7 res reserved. read as zero. always write as zero. bit 6 bswp byte swap. the bswp function allows data to and from the fifos to be orientated accord- ing to little endian or big endian byte ordering conventions. bswp is cleared by by activa- tion of the reset pin or swrst bit, defaulting to intel byte ordering. bit 5-4 xmtsp transmit start point. xmtsp [1-0] controls the point preamble transmission commences in relation to the number of bytes written to the xmtfifo. when the entire frame is in the xmt- fifo (or the xmtfifo becomes full before the threshold is achieved), transmission of pre- amble will start regardless of the value in xmtsp (once the ipg time has expired). xmtsp is given a value of 10 (64 bytes) after hardware or software reset. regardless of xmtsp, the fifo will not internally over write its data until at least 64 bytes, or the entire frame, has been transmit- ted onto the network. this ensures that for collisions within the slot time window, transmit data need not be re-written to the xmtfifo, and re-tries will be handled autonomously by the mace device. xmtsv tdtreq rdtreq res res res res res res bswp xmtsp [1-0] res res res swrst
am79c940 65 transmit start point bit 3-1 res reserved. read as zeroes. al- ways write as zeroes. bit 0 swrst software reset. when set, pro- vides an equivalent of the hard- ware reset pin function. all register bits will be set to their default values. the mace de- vice will require re-initialization after swrst has been activat- ed. the mace device will clear swrst during its internal reset sequence. fifo configuration control (reg addr 12) (fifocc) all bits within the fifo configuration control register will be set to their default state upon a hardware or soft- ware reset. bit assignments are as follows: bit name description bit 7-6 xmtfw transmit fifo watermark. [1-0] xmtfw controls the point tdtreq is asserted in relation to the number of write cycles to the transmit fifo. tdtreq will be asserted at any time that the number of write cycles specified by xmtfw can be executed. xmtfw is set to a value of 00 (8 cycles) after hardware or software reset. transmit fifo watermarks the xmtfw value will only be updated when the xmtfwu bit is set. to ensure that sufficient space is present in the xmtfifo to accept the specified number of write cycles (including an end-of-frame delimiter), tdtreq may go inactive before the xmtsp threshold is reached when using the non burst mode (xmtbrst = 0). the host must be aware that despite tdtreq going inactive, additional space exists in the xmtfifo, and the data write must continue to ensure the xmtsp threshold is achieved. no transmit activity will commence until the xmtsp threshold is reached. when using the burst mode, tdtreq will not be de-asserted until only a single write cycle can be per- formed. see the fifo sub-sys- tem section for additional de- tails. bit 5-4 rcvfw receive fifo watermark. [1-0] rcvfw controls the point rdtreq is asserted in relation to the number of bytes available in the rcvfifo. rcvfw speci- fies the number of bytes which must be present (once the pack- et has been verified as a non-runt), before the rdtreq is asserted. note however that in order for rdtreq to be activat- ed for a new frame, at least 64-bytes must have been received. this effectively avoids reacting to receive frames which are runts or suffer a collision dur- ing the slot time (512 bit times). if the runt packet accept fea- ture (rpa in receive frame control) is enabled, the rdtreq pin will be activated as soon as either 64-bytes are received, or a complete valid receive frame is detected (regardless of length). rcvfw is set to a value of 10 (64 bytes) after hardware or software reset. receive fifo watermarks the rcvfw value will only be updated when the rcvfwu bit is set. bit 3 xmtfwu transmit fifo watermark update. allows update of the xmtsp [1-0] bytes 00 4 01 16 10 64 11 112 xmtfw[1-0] rcvfw [1-0] xmtfwu rcvfwu xmtbrst rcvbrst xmtsp [1 ? 0] bytes 00 8 01 16 10 32 11 xx xmtsp [1 ? 0] bytes 00 16 01 32 10 64 11 xx
66 am79c940 transmit fifo watermark bits. the xmtfw can be written at any point, and will be read back as written. however, the new value in the xmtfw bits will be ignored until xmtfwu is set (or the transmit path is reset due to a retry failure). the recommend- ed procedure to change the xmtfw is to write the new value with xmtfwu set, in a single write cycle. the xmtfifo should be empty and all transmit activity complete before attempt- ing a watermark update, since the xmtfifo will be reset to allow the new pointer values to be loaded. it is recommended that the transmitter be disabled by clearing the enxmt bit. xmtfwu will be cleared by the mace device after the new xmtfw value has been loaded, or by activation of the reset pin or swrst bit. bit 2 rcvfwu receive fifo watermark update. allows update of the receive fifo watermark bits. the rcvfw bits can be written at any point, and will read back as written. however, the new value in the rcvfw bits will be ignored until rcvfwu is set. the recommended procedure to change the rcvfw is to write the new value with rcvfwu set, in a single write cycle. the rcvfifo should be empty before attempting a watermark update, since the rcvfifo will be reset to allow the new pointer values to be loaded. it is recom- mended that the receiver be dis- abled by clearing the enrcv bit. rcvfwu will be cleared by the mace device after the new rcvfw value has been loaded, or by activation of the reset pin or swrst bit. bit 1 xmtbrst transmit burst. when set, the transmit burst mode is selected. the behavior of the transmit fifo high watermark, and hence the de-assertion of tdtreq , will be modified. tdtreq will be deasserted if there are only two bytes of space available in the xmtfifo (so that a full word write can still occur) or if four bytes of space exist and the eof pin is assert- ed by the host.tdtreq will be asserted identically in both normal and burst modes, when there is sufficient space in the xmtfifo to allow the specified number of write cycles to occur (programmed by the xmtfw bits). cleared by activation of the reset pin or swrst bit. bit 0 rcvbrst receive burst. when set, the receive burst mode is selected. the behavior of the receive fifo low watermark, and hence the de-assertion of rdtreq , will be modified. rdtreq will de-assert when there are only 2-bytes of data available in the rcvfifo (so that a full word read can still occur). rdtreq will be asserted identi- cally in both normal and burst modes, when a minimum of 64-bytes have been received for a new frame (or a runt packet has been received and rpa is set). once the 64-byte limit has been exceeded, rdtreq will be asserted providing there is sufficient data in the rcvfifo to exceed the threshold, as pro- grammed by the rcvfw bits. cleared by activation of the reset pin or swrst bit. mac configuration control (maccc) (reg addr 13) this register programs the transmit and receive opera- tion and behavior of the internal mac engine. all bits within the mac configuration control register are cleared upon hardware or software reset. bit assignments are as follows: bit name description bit 7 prom promiscuous. when prom is set all incoming frames are received regardless of the desti- nation address. prom is cleared by activation of the reset pin or swrst bit. bit 6 dxmt2pd disable transmit two part deferral. when set, disables the transmit two part deferral option. dxmt2pd is cleared by activation of the reset pin or swrst bit. bit 5 emba enable modified back-off algo- rithm. when set, enables the prom dxmt2pd emba res drcvpa drcvbc enxmt enrcv
am79c940 67 modified backoff algorithm. emba is cleared by activation of the reset pin or swrst bit. bit 4 res reserved. read as zeroes. always write as zeroes. bit 3 drcvpa disable receive physical address. when set, the physical address detection (station or node id) of the mace device will be disabled. packets addressed to the nodes individual physical address will not be recognized (although the packet may be accepted by the eadi mecha- nism). drcvpa is cleared by activation of the reset pin or swrst bit. bit 2 drcvbc disable receive broadcast. when set, disables the mace device from responding to broadcast messages. used for protocols that do not support broadcast addressing, except as a function of multicast. drcvbc is cleared by activation of the reset pin or swrst bit (broadcast messages will be received). bit 1 enxmt enable transmit. setting enxmt = 1 enables transmis- sion. with enxmt = 0, no trans- mission will occur. if enxmt is written as 0 during frame trans- mission, a packet transmission which is incomplete will have a guaranteed crc violation appended before the internal transmit fifo is cleared. no subsequent attempts to load the fifo should be made until enxmt is set and tdtreq is asserted. enxmt is cleared by activation of the reset pin or swrst bit. bit 0 enrcv enable receive. setting enrcv = 1 enables reception of frames. with enrcv = 0, no frames will be received from the network into the internal fifo. when enrcv is written as 0, any receive frame currently in progress will be completed (and valid data contained in the rcvfifo can be read by the host) and the mace device will enter the monitoring state for missed packets. note that clearing the enrcv bit disables the assertion of rdtreq . if enrcv is cleared during re- ceive activity and remains cleared for a long time and if the tail end of the receive frame cur- rently in progress is longer than the amount of space available in the receive fifo, receive fifo overflow will occur. how- ever, even with rdtreq deas- serted, if there is valid data in the receive fifo to be read, suc- cessful slave reads to the receive fifo can be executed (indicated by valid dtv ). it is the host ? s responsibility to avoid the overflow situation. enrcv is cleared by activation of the reset pin or swrst bit. pls configuration control (plscc) (reg addr 14) all bits within the pls configuration control register are cleared upon a hardware or software reset. bit assignments are as follows: bit name description bit 7-4 res reserved. read as zeroes. always write as zeroes. bit 3 xmtsel transmit mode select. xmtsel provides control over the aui do+ and do ? operation while the mace device is not transmit- ting. with xmtsel = 0, do+ and do will be equal during transmit idle state, providing zero differential to operate trans- former coupled loads. the turn off and return to zero delays are controlled internally. with xmtsel = 1, do+ is positive with respect to do during the transmit idle state . bit 2-1 portsel port select. portsel is used [1-0] to select between the aui, 10base ? t, dai or gpsi ports of the mace device. portsel is cleared by hardware or soft- ware reset. portsel will deter- mine which of the interfaces is used during normal operation, or tested when utilizing the loop- back options (loop [1-0]) in the user test register. note that the portsel [1 ? 0] program- ming will be overridden if the asel bit in the phy configura- tion control register is set. res res res res xmtsel portsel [1-0] enplsio
68 am79c940 portsel interface definitio n bit 0 enplsio enable pls i/o. enplsio is used to enable the optional i/o functions from the pls function. the following pins are affected by the enplsio bit: rxcrs, rxdat, txen , txdat+, txdat-, clsn, stdclk, rdclk and srd. note that if an external sia is being utilized via the gpsi, portsel [1 ? 0] = 11 must be programmed before enplsio is set, to avoid con- tention of clock, data and/or carrier indicator signals. phy configuration control (phycc) (reg addr 15) all bits within the phy configuration control register with the exception of lnkfl, are cleared by hardware or software reset. bit assignments are as follows: bit name description bit 7 lnkfl link fail. reports the link integ- rity of the 10base ? t receiver. when the link test function is enabled (dlnktst = 0), the absence of link beat pulses on the rxd pair will cause the integrated 10base ? t transceiv- er to go into the link fail state. in the link fail state, data transmis- sion, data reception, data loop- back and the collision detection functions are disabled, and remain disabled until valid data or >5 consecutive link pulses appear on the rxd pair. during link fail, the lnkfl bit will be set and the lnkst pin should be externally pulled high. when the link is identified as function- al, the lnkfl bit will be cleared and the lnkst pin is driven low, which is capable of direct- ly driving a link ok led. in order to inter-operate with sys- tems which do not implement link test, this function can be disabled by setting the dlnktst bit. with link test disabled (dlnktst = 1), the data driver, receiver and loop- back functions as well as colli- sion detection remain enabled irrespective of the presence or absence of data or link pulses on the rxd pair. the transmitter will continue to generate link beat pulses during periods of transmit data inactivity. set by hardware or software reset. bit 6 dlnktst disable link test. when set, the integrated 10base ? t transceiv- er will be forced into the link pass state, regardless of receive link test pulses or receive packet activity. bit 5 revpol reversed polarity. indicates the receive polarity of the rd pair. when normal polarity is detect- ed, the revpol bit will be cleared, and the rxpol pin (capable of driving a polarity ok led) will be driven low. when reverse polarity is detected, the revpol bit will be set, and the rxpol pin should be externally pulled high. bit 4 dapc disable auto polarity correction. when set, the automatic polarity correction will be disabled. polarity detection and indication will still be possible via the rxpol pin. bit 3 lrt low receive threshold. when set, the threshold of the twisted pair receiver will be reduced by 4.5 db, to allow extended dis- tance operation. bit 2 asel auto select. when set, the portsel [1-0] bits are overrid- den, and the mace device will automatically select the operat- ing media interface port. when the 10base ? t transceiver is in the link pass state (due to receiv- ing valid packet data and/or link test pulses or the dlnktst bit is set), the 10base-t port will be used. when the 10base ? t port is in the link fail state, the aui port will be used. switching between the ports will not occur during transmission in order to avoid any type of fragment generation. bit 1 rwake remote wake. when set prior to the sleep pin being activated, the aui and 10base ? t receiver sections and the eadi port will portsel [1 ? 0] active interface dxcvr pin 00 aui low 01 10base ? thigh 10 dai port high 11 gpsi low lnkfl dlnktst revpol dapc lrt asel rwake awake
am79c940 69 continue to operate even during sleep . incoming packet activity will be passed to the eadi port pins permitting detection of spe- cific frame contents used to ini- tiate a wake-up sequence. rwake must be programmed prior to sleep being asserted for this function to operate. rwake is not cleared by sleep , only by activation of the swrst bit or reset pin. bit 0 awake auto wake. when set prior to the sleep pin being activated, the 10base-t receiver section will continue to operate even during sleep , and will activate the lnkst pin if link pass is detected. awake must be pro- grammed prior to sleep being asserted for this function to operate. awake is not cleared by sleep , only by activation of the swrst bit or reset pin. chip identification register (chipid [15-00]) (reg addr 16 &17) this 16-bit value corresponds to the specific version of the mace device being used. the value will be programmed to x940h, where x is a value dependent on version. [for the current version of the mace de- vice, x = 3 to denote rev c0 silicon.] internal address configuration (iac) (reg addr 18) this register allows access to and from the multi-byte physical address and logical address filter locations, using only a single byte location. the mace device will reset the iac register phyaddr and logaddr bits after the appropriate number of read or write cycles have been executed on the physical address register or the logical address filter. once the logaddr bit is set, the mace device will reset the bit after 8 read or write operations have been performed. once the phyaddr bit is set, the mace device will reset the bit after 6 read or write operations have been performed. the mace device makes no distinction be- tween read or write operations, advancing the internal address ram pointer with each access. if both phy- addr and logaddr bits are set, the mace device will accept only the logaddr bit. if the phyaddr bit is set and the logical address filter location is ac- cessed, a dtv will not be returned. similarly, if the logaddr bit is set and the physical address register location is accessed, dtv will not be returned. phy- addr or logaddr can be set in the same cycle as addrchg. bit name description bit 7 addrchg address change. when set, allows the physical and/or logi- cal address to be read or pro- grammed. when addrchg is set, enrcv will be cleared, the mpc will be stopped, and the last or current in progress receive frame will be received as normal. after the frame com- pletes, access to the internal address ram will be permitted, indicated by the mace device clearing the addrchg bit. please refer to the register description of the enrcv bit in the mac configuration control register (reg addr 13) for the effect of clearing the enrcv bit. normal reception can be resumed once the physical/logi- cal address has been changed, by setting enrcv. bit 6-3 res reserved. read as zeroes. always write as zeroes. bit 2 phyaddr physical address reset. when set, successive reads or writes to the physical address register will occur in the order padr [07 ? 00], padr [15 ? 08],...., padr [47 ? 40]. each read or write operation on the padr location will auto-increment the internal pointer to access the next most significant byte. bit 1 logaddr logical address reset. when set, successive reads or writes to the logical address filter will occur in the order ladrf [07 ? 00], ladrf [15-08],....,ladrf [63 ? 56]. each read or write operation on the ladrf location will auto-increment the internal pointer to access the next most significant byte. bit 0 res reserved. read as zero. always write as zero. logical address filter (ladrf [63 ? 00]) (reg addr 20) this 64-bit mask is used to accept incoming logical addresses. the logical address filter is expected to be programmed at initialization (after hardware or chipid [07 ? 00] chipid [15 ? 08] addrchg res res res res phyaddr logaddr res ladrf [63 ? 00]
70 am79c940 software reset). after a hardware or software reset and before the enrcv bit in the mac configuration con- trol register has been set, the logical address can be accessed by setting the log addr bit in the internal address configuration register (reg addr 18) and then by performing 8 reads or writes to the logical address filter. once enrcv has been set, the addr chg bit in the internal address configuration register must be set and be polled until it is cleared by the mace device before setting the logaddr bit and before accessing of the logical address filter is allowed. if the least significant address bit of a received message is set (destination address bit 00 = 1), then the address is deemed logical, and passed through the fcs generator. after processing the 48-bit destination address, a 32-bit resultant fcs is produced and strobed into an internal register. the high order 6-bits of this resultant fcs are used to select one of the 64-bit positions in the logical address filter (see diagram). if the selected filter bit is a 1 , the address is accepted and the packet will be placed in memory. the first bit of the incoming address must be a 1 for a logical address. if the first bit is a 0 , it is a physical address and is compared against the value stored in the physical address register at initialization. the logical address filter is used in multicast address- ing schemes. the acceptance of the incoming frame based on the filter value indicates that the message may be intended for the node. it is the user ? s responsi- bility to determine if the message is actually intended for the node by comparing the destination address of the stored message with a list of acceptable logical addresses. the broadcast address, which is all ones, does not go through the logical address filter and is always enabled provided the disable receive broadcast bit (drcvbc in the mac configuration control register) is cleared. if the logical address filter is loaded with all zeroes (and prom = 0), all incoming logical addresses except broadcast will be rejected. multicast addressing can only be performed when using external loopback (loop [1 ? 0] = 0) by pro- gramming rcvfcse = 1 in the user test register. the fcs logic is internally allocated to the receiver section, allowing the fcs to be computed on the in- coming logical address. 47 1 0 received message destination address 1 crc gen sel 31 26 0 mux match* match = 1: match = 0: packet accepted packet rejected 63 0 6 64 logical address filter (ladrf) 32-bit resultant crc 16235d-10 logical address match logic
71 physical address (padr [47-00]) (reg addr 21 ) this 48-bit value represents the unique node value assigned by the ieee and used for internal address comparison. after a hardware or software reset and before the enrcv bit in the mac configuration con- trol register has been set, the physical address can be accessed by setting the phyaddr bit in the internal address configuration register (reg addr 18) and then by performing 6 reads or writes to the physical address. once enrcv has been set, the addrchg bit in the internal address configuration register must be set and be polled until it is cleared by the mace device before setting the phyaddr bit and before accessing of the physical address is allowed. the first bit of the incoming address must be a 0 for a physical address. the incoming address is compared against the value stored in the physical address register at ini- tialization provided that the drcvpa bit in the mac configuration control register is cleared. missed packet count (mpc) (reg addr 24) the missed packet count (mpc) is a read only 8-bit counter. the mpc is incremented when the receiver is unable to respond to a packet which would have nor- mally been passed to the host. the mpc will be reset to zero when read. the mace device will be deaf to receive traffic due to any of the following conditions: the host disabled the receive function by clearing the enrcv bit in the mac configuration control register. a receive fifo overflow condition exists, and must be cleared by reading the receive fifo and the receive frame status. the receive frame count (rcvfc) in the fifo frame count register exceeds its maximum value, indicating that greater than 15 frames are in the receive fifo. if the number of received frames that have been missed exceeds 255, the mpc will roll over and con- tinue counting from zero, the mpco (missed packet count overflow) bit in the interrupt register will be set (at the value 255), and the intr pin will be asserted providing that mpcom (missed packet count overflow mask) in the interrupt mask register is clear. mpcom will be cleared (the interrupt will be unmasked) after a hardware or software reset. note that the following conditions apply to the mpc: after hardware or software reset, the mpc will not increment until the first time the receiver is enabled (enrcv = 1). once the receiver has been enabled, the mpc will count all missed packet events, regardless of the programming of enrcv. the packet must pass the internal address match to be counted. any of the following address match conditions will increment mpc while the receiver is deaf : physical address match; logical address match; broadcast reception; any receive in promiscuous mode (prom = 1 in the mac configuration control register); eadi feature match mode and eam is asserted; eadi feature reject mode and ear is not asserted. any packet which suffers a collision within the slot time will not be counted. runt packets will not be counted unless rpa in the user test register is enabled. packets which pass the address match criteria but experience fcs or framing errors will be counted, since they are normally passed to the host. runt packet count (rntpc) (reg addr 26) the runt packet count (rntpc) is a read only 8-bit counter, incremented when the receiver detects a runt packet that is addressed to this node. runt packets are defined as received frames which passed the internal address match criteria but did not contain a minimum of 64-bytes of data after sfd. note that the rntpc value returned in the receive frame status (rfs2) will freeze at a value of 255, whereas this register based version of rntpc is free running. the value will roll over after 255 runt packets have been detected, setting the rntpco bit (in the interrupt register and assert- ing the intr pin if the corresponding mask bit (rntp- com in the interrupt mask register) is cleared. rntpc will be reset to zero when read. receive collision count (rcvcc)(reg addr 27) the receive collision count (rcvcc) is a read only 8-bit counter, incremented when the receiver detects a collision on the network. note that the rcvcc value returned in the receive frame status (rfs3) will freeze at a value of 255, whereas this register based version of rcvcc is free running. the value will roll over after 255 receive collisions have been detected, setting the rcvcco bit (in the interrupt register and asserting the intr pin if the corresponding mask bit (rcvccom in the interrupt mask register) is cleared. rcvcc will be reset to zero when read. user test register (utr) (reg addr 29) the user test register is used to put the chip into test configurations. all bits within the test register are cleared upon a hardware or software reset. bit assignments are as follows: padr [47 ? 00] mpc [7 ? 0] rtre rtrd rpa fcoll rcvfcse loop [1-0] fd_test rntpc [7 ? 0] rcvcc [7 ? 0]
72 bit name description bit 7 rtre reserved test register enable. access to the reserved test registers should not be attempt- ed by the user. note that access to the reserved test register may cause damage to the mace device if config- ured in a system board appli- cation. access to the reserved test register is prevented, regardless of the state of rtre, once rtrd has been set. rtre is cleared by activation of the reset pin or swrst bit. bit 6 rtrd reserved test register disable. when set, access to the reserved test registers is inhibited, and further writes to the rtrd bit are ignored. access to the reserved test register is prevented, regard- less of the state of rtre, once rtrd has been set. rtrd can only be cleared by hardware or software reset. bit 5 rpa runt packet accept. allows receive packets which are less than the legal minimum as spec- ified by ieee 802.3/ethernet, to be passed to the host interface via the receive fifo. the receive packets must be at least 8 bytes (after sfd) in length to be accepted. rpa is cleared by activation of the reset pin or swrst bit. bit 4 fcoll force collision. allows the colli- sion logic to be tested. the mace device should be in an internal loopback test for the fcoll test. when fcoll = 1, a collision will be forced during the next transmission attempt. this will result in 16 total transmis- sion attempts (if drtry = 0) with the retry error reported in the transmit frame status reg- ister. fcoll is cleared by the activation of the reset pin or swrst bit. bit3 rcvfcse receive fcs enable. allows the hardware associated with the fcs generation to be allocated to the transmitter or receiver dur- ing loopback diagnostics. when clear, the fcs will be generated and appended to the transmit message (providing that dxmt- fcs in the transmit frame con- trol is clear), and received after the loopback process through the receive fifo. when set, the hardware associated with the fcs generation is allocated to the receiver. a transmit packet will be assumed to contain the fcs in the last four bytes of the frame passed through the transmit fifo. the received frame will have the fcs calcu- lated on the data field and com- pared with the last four bytes contained in the received mes- sage. an fcs error will be flagged in the received status (rfs1) if the received and cal- culated values do not match. rcvfcse is only valid when in any one of the loopback modes as defined by loop [0 ? 1]. note that if the receive frame is expected to be recognized on the basis of a multicast address match, the fcs logic must be allocated to the receiver (rcvfcse = 1). rcvfcse is cleared by activation of the reset pin or swrst bit. bit 2-1 loop [1-0] loopback control. the loopback functions allow the mace device to receive its own trans- mitted frames. three levels of loopback are provided as shown in the following table. during loopback operation a multicast address can only be recognized if rcvfcse = 1. loop [0-1] are cleared by activation of the reset pin or swrst bit loopback functions external loopback allow the mace device to transmit to the physical medium, using either the aui, 10base ? t, dai or gpsi port, dependent on the portsel [1 ? 0] bits in the pls configuration control register. using the internal loopback test will ensure that transmission loop [1 ? 0] function 00 no loopback 01 external loopback 10 internal loopback, excludes mendec 11 internal loopback, includes mendec
73 does not disturb the physical medium and will prohibit frame reception from the network. one internal loopback function in- cludes the mendec in the loop. bit 0 fd_test full duplex test. when set, will allow the mace device to transmit back to back packets with 9.6 s ipg regardless of receive activities. the setting of this bit should also be in conjunction with the setting of bit 0 of the transmit frame con- trol (xmtfc) (reg addr 2). the setting of bit 0 of the xmtfc register will cause dis- abling of transmit fcs. to activate full duplex test mode, program the mace device into external loopback mode (exloop=1, inloop=0) and set fd_test=1. the code sequence would be as follows: write 2 08 ;register xmtfc, transmit fcs disable write 29 0b ;register utr, receive fcs enable external loop enable, full duplex enable reserved test register 1 (rtr1) (reg addr 30) reserved for amd internal use only. reserved test register 2 (rtr2) (reg addr 31) reserved for amd internal use only.
74 register table summary address mnemonic contents comments 0 rcvfifo receive fifo [15 ? 00] read only 1 xmtfifo transmit fifo [15 ? 00] write only 2 xmtfc transmit frame control read/write 3 xmtfs transmit frame status read only 4 xmtrc transmit retry count read only 5 rcvfc receive frame control read/write 6 rcvfs receive frame status (4-bytes) read only 7 fifofc fifo frame count read only 8 ir interrupt register read only 9 imr interrupt mask register read/write 10 pr poll register read only 11 biucc biu configuration control read/write 12 fifocc fifo configuration control read/write 13 maccc mac configuration control read/write 14 plscc pls configuration control read/write 15 phycc phy configuration control read/write 16 chipid chip identification register [07 ? 00] read only 17 chipid chip identification register [15 ? 08] read only 18 iac internal address configuration read/write 19 reserved read/write as 0 20 ladrf logical address filter (8-bytes) read/write 21 padr physical address (6-bytes) read/write 22 reserved read/write as 0 23 reserved read/write as 0 24 mpc missed packet count read only 25 reserved read/write as 0 26 rntpc runt packet count read only 27 rcvcc receive collision count read only 28 reserved read/write as 0 29 utr user test register read/write 30 rtr1 reserved test register 1 read/write as 0 31 rtr2 reserved test register 2 read/write as 0
75 register bit summary 16-bit registers 8-bit registers receive frame status 0 rcvfifo [15 ? 0] 1 xmtfifo [15 ? 0] address mnemonic 2 drtry res res res dxmtfcs res res apadxmt 3 xmtsv uflo lcol more one defer lcar 4 exdef res res res xmtrc [3 ? 0] 5 res res res res llrcv m/r res astrprcv 6 rcvfs [31 ? 00] 7 rcvfc [3 ? 0] xmtfc [3 ? 0] 8 jab babl cerr rcvcco rntpco mpco rcvint xmtint 9 jabm bablm cerrm rcvccom rntpcom mpcom rcvintm xmtintm 10 xmtsv tdtreq rdtreq res res res res res 11 res bswp xmtsp [1 ? 0] res res res swrst 12 xmtfw [1 ? 0] rcvfw [1 ? 0] xmtfwu rcvfwu xmtbrst rcvbrst 13 prom dxmt2pd emba res drcvpa drcvbc enxmt enrcv 14 res res res res xmtsel portsel [1 ? 0] enplsio 15 lnkfl dlnktst revpol dapc lrt asel rwake awake 16 chipid [07 ? 00] 17 chipid [15 ? 08] 18 addrchg res res res res phyaddr logaddr res 19 reserved 20 ladrf [63 ? 00] 21 padr [47 ? 00] 22 reserved 23 reserved 24 mpc [7 ? 0] 25 reserved 26 rntpc [7 ? 0] 27 rcvcc [7 ? 0] 28 reserved 29 rtre rtrd rpa fcoll rcvfcse loop [1 ? 0] res 30 reserved 31 reserved address mnemonic rfs0 rcvcnt [7:0] rfs1 oflo clsn fram fcs rcvcnt [10:8] rfs2 rntpc [7 ? 0] rfs3 rcvcc [7 ? 0]
76 programmer ? s register model addr mnemonic contents r/w 0 rcvfifo receive fifo ? 16 bits ro 1 xmtfifo transmit fifo ? 16 bits wo 2 xmtfc transmit frame control 80 drtry disable retry 08 dxmtfc disable transmit fcs 01 apadxmt auto pad transmit r/w 3 xmtfs transmit frame status 80 xmtsv transmit status valid 40 uflo underflow 20 lcol late collision 10 more more than one retry was needed 08 one exactly one retry occurred 04 defer transmission was deferred 02 lcar loss of carrier 01 rtry transmit aborted after 16 attempts r/w 4 xmtrc 80 exdef excessive defer 40 ? 20 ? 10 ? 0f xmtrc [3:0] 4-bit transmit retry count ro 5 rcvfc receive frame control 08 llrcv low latency receive 04 m/r match/reject for external address detection 01 astrprcv auto strip receive ? strips pad and fcs from received frames r/w 6 rcvfs receive frame status ? 4 bytes ? read in 4 read cycles rfs0 rcvcnt [7:0] receive message byte count rfs1 rcvsts, rcvcnt [11:8] ? receive status & receive msg byte count msbs 80 oflo receive fifo overflow 40 clsn collision during reception 20 fram framing error 10 fcs fcs (crc) error 0f rcvcnt [11:8] 4 msbs of receive msg. byte count rfs2 rntpc [7:0] runt packet count (since last successful reception) rfs3 rcvcc [7:0] receive collision count (since last successful reception) ro 7 fifofc fifo frame count f0 rcvfc receive frame count ? # of rcv frames in fifo 0f xmtfc transmit frame count ? # of xmt frames in fifo ro ro
77 8 ir interrupt register 80 jab jabber error ? excessive transmit during (20 ? 150ms) 40 babl babble error ? 1518 bytes transmitted 20 cerr collision error ? no sqe test message 10 rcvcco receive collision count overflow ? red add 27 overflow 08 rntpco runt packet count overflow ? reg addr 26 overflow 04 mpco missed packet count overflow ? reg addr 24 overflow 02 rcvint receive interrupt ? host has read last byte of packet 01 xmtint transmit interrupt ? transmission is complete ro 9 imr interrupt mask register 80 jabm jabber error mask 40 bablm babble error mask 20 cerrm collision error mask 10 rcvccom receive collision count overflow mask 08 rntpcom runt packet count overflow mask 04 mpcom missed packet count overflow mask 02 rcvintm receive interrupt mask 01 xmtintm transmit interrupt mask r/w 10 pr poll register 80 xmtsv transmit status valid 40 tdtreq transmit data transfer request 20 rdtreq receive data transfer request ro 11 biucc bus interface unit configuration control 80 ? 40 bswp byte swap 30 xmtsp ? transmit start point (2 bits) 00 transmit after 4 bytes have been loaded 01 transmit after 16 bytes have been loaded 10 transmit after 64 bytes have been loaded 11 transmit after 112 bytes have been loaded 01 swrst software reset r/w addr mnemonic contents r/w
78 programmer ? s register model (continued) addr mnemonic contents r/w 12 fifocc fifo configuration control c0 xmtfw transmit fifo watermark (2 bits) 00 assert tdtreq after 8 write cycles can be made 01 assert tdtreq after 16 write cycles can be made 10 assert tdtreq after 32 write cycles can be made 11 xx 30 rcvfw receive fifo watermark (2 bits) 00 assert rdtreq after 16 bytes are present 01 assert rdtreq after 32 bytes are present 10 assert rdtreq after 64 bytes are present 11 xx 08 xmtfwu transmit fifo watermark update ? loads xmtfw bits 04 rcvfwu receive fifo watermark update ? loads rcvfw bits 02 xmbrst select transmit burst mode 01 rcvbrst select receive burst mode r/w 13 maccc media access control (mac) configuration control 80 prom promiscuous mode 40 dxmt2pd disable transmit two part deferral 20 emba enable modified back-off algorithm 10 ? 08 drcvpa disable receive physical address 04 drcvbc disable receive broadcast 02 enxmt enable transmit 01 enrcv enable receive r/w 14 plscc physical layer signalling (pls) configuration control 08 xmtsel transmit mode select: 1 ? do =1 during idle 06 portsel [1:0] ? port select (2 bits) 00 aui selected 01 10base-t selected 10 dai port selected 11 gpsi selected 01 enplsio enable status r/w
79 programmer ? s register model (continued) addr mnemonic contents r/w 15 phycc physical layer (phy) configuration control 80 lnkfl link fail ? reports 10base-t receive inactivity 40 dlnktst disable link test ? force 10base ? t port into link pass 20 revpol reversed polarity ? reports 10base-t receiver wiring error 10 dapc disable auto polarity correction ? detection remains active 08 lrt low receive threshold ? extended distance capability 04 asel auto select ? select 10base-t port when active, otherwise aui 02 rwake remote wake ? 10base-t, aui and eadi features active during sleep 01 awake auto wake ? 10base-t receive and lnkst active during sleep r/w 16 chipid chip identification register lsb ? chipid [7:0] ro 17 chipid chip identification register msb ? chipid [15:8] ro 18 iac internal address configuration 80 addrchg address change ? write to phyaddr or logaddr after enrcv 40 ? 20 ? 10 ? 08 ? 04 ? 04 phyaddr reset physical address pointer 02 logaddr reset logical address pointer 01 ? r/w 19 ? reserved r/w as 0 20 ladrf logical address filter ? 8 bytes ? 8 reads or writes ? ls byte first r/w as 0 21 padr physical 6 bytes ? 6 reads or writes ? ls byte first r/w as 0 22 ? reserved r/w as 0 23 ? reserved r/w as 0 24 mpc missed packet counter ? number of receive packets missed r/w as 0 25 ? reserved r/w as 0 26 rntpc runt packet count ? number of runt packets addressed to this node r/w as 0 27 rcvcc receive collision count ? number of receive collision frames on network r/w as 0 28 ? reserved r/w as 0
80 missing table title? system applications host system examples motherboard dma controller the block diagram shows the mace device interfacing to a 8237 type dma controller. two external latches are used to provide a 24 bit address capability. the first latch stores the address bits a [15:8], which the 8237 will output on the data line db [7:0], while the signal adstb is active. the second latch is used as a page register. it extends the addressing capability of the 8237 from 16 ? bit to 24 ? bit. this latch must be pro- grammed by the system using an i/0 command to gen- erate the signal latchhighadr. the mace device uses two of the four dma channels. one is dedicated to fill the transmit fifo and the other to empty the receive fifo. both dma channels should be programmed in the following mode: ? command register: memory to memory disabled dreq sense active high dack sense active low normal timing late write note: this is the same configuration as used in the ibm pc. the 8237 and the mace device run synchronous to the same sclk. the 8237 is programmed to execute a transfer in three clock cycles this requires an extra wait state in the mace device during fifo accesses. a system not using the same configuration as in the ibm pc can minimize the bus bandwidth required by the mace device by programming the dma controller in the compressed timing mode. care must be taken with respect to the number of transfers within a burst. the 8237 will drive the signal eop low every time the internal counter reaches the zero. the mace device however only expects eof as- serted on the last byte/word of a packet. this means, that the word counter of the 8237 should be initially loaded with the number of bytes/words in the whole packet. if the application requires that the packet will be constructed from several buffers at transmit time, some extra logic is required to suppress the assertion of eof at the end of all but the last buffer transferred by the dma controller. also note that the dma controller can only handle either bytes or words at any time. it re- quires special handling if a packet is transferred to the mace device transmit fifo in word quantities and it ends in an odd byte. the 8237 requires an extra clock cycle to update the external address latch every 256 transfer cycles. this example assumes that an update of the external address latch occurs only at the beginning of the block transfer. addr mnemonic contents r/w 29 utr user test register 80 rtre 40 rtrd 20 rpa 10 fcoll 08 rcvfcse 06 loop 00 01 10 11 01 reserved test register enable ? must be 0 reserved test register disable runt packet accept force collision receive fcs enable loopback control (2 bits) no loopback external loopback internal loopback, excludes mendec internal loopback, includes mendec ? r/w r/w 30 ? reserved r/w as 0 31 ? reserved r/w as 0
81 d[7:0] q[7:0] c sclk dreq0 dreq1 eop dack0 dack1 adstb db[7:0] a[7:0] 8237 d[7:0] q[7:0] c cc ? 373 d[7:0] cc ? 373 sclk rdtreq tdtreq eof fds am79c940 cs clk iow csmace latchhighadr d[15:0] a[23:0] tc dbus[15:0] add[4:0] v dd 16235d-11 r/w system interface - motherboard dma example
82 pc/at ethernet adapter card i s a b u s sd7-sd0 sd15-sd8 aui am79c940 tp rj45 ieee address prom gpsi/dai header remote boot prom cam d7-d0 d15-d8 db15 sa19-sa0 16235d-12 system interface - simple pc/at ethernet adapter card example
83 network interfaces external address detection interface (eadi) the external address detection interface can be used to implement alternative address recognition schemes outside the mace device, to complement the physical, logical and promiscuous detection supported internally. the address matching, and the support logic neces- sary to capture and present the relevant data to the ex- ternal table of address is application specific. note that since the entire 802.3 packet after sfd is made avail- able, recognition is not limited to the destination ad- dress and/or type fields (ethernet only). inter-networking protocol recognition can be performed on specific header or llc information fields. q h ? 74ls595 74ls595 74ls245 74ls245 ser srck rck q h ? q h-a a8-a1 b8-b1 eadi pins ser srck rck a8-a1 b8-b1 srd srdclk sf/bd logic block eam/r am99c10 d15-d0 mtch cam programming interface databus databus 16235d-13 q h-a eadi feature - simple external cam interface
84 attachment unit interface (aui) the aui can drive up to 50 m of standard drop cable to allow the transceiver to be remotely located, as is typi- cally the case in ieee 803.3 10base5 or thick ether- net ? installations. for a locally mounted transceiver, such as 802.3 10base2 or cheapernet interface, the isolation transformer requirements between the trans- ceiver and the mace device can be reduced. when used with the am79c98 tpex ? (twisted pair ethernet transceiver), the isolation requirements of the aui are completely removed providing that the trans- ceiver is mounted locally. for remote location of the tpex via an aui drop cable, the isolation requirement is necessary to meet ieee 802.3 specifications for fault tolerance and recovery. cpu memory power supply local bus 10base5/ethernet dte aui cable mau ta p am7996 transceiver ethernet coax 16235d-14 am79c940 aui-10base5/ethernet example rg58 bnc ? t ? system cpu local memory 10base2/cheapernet cheapernet coax power supply am7996 transceiver am79c940 dma engine i/o bus 16235d-15 aui-10base2/cheapernet example
85 system cpu other slave i/o device(s) i.e. scsi am79c9416 mace 10base-t/twisted-pair etherne t am79c940 i/o processor slave peripheral bus rj45 unshielded twisted-pair 16235d-16 10base-t/unshielded twisted-pair interface
86 xmt filter rcv filter anlg gnd anlg +5 v avss avdd 0.1 f filter & transformer module note 1 note 2 am79c940 txp+ txd- txp- txd+ rxd+ rxd- 0.1 f lnkst link ok dgtl +5 v rxpol rx pol ok 1.21k ? 100 ? 61.9 ? 422 ? 61.9 ? 422 ? do- di+ di- ci+ ci- do+ pulse transformer note 3 40.2 ? optional anlg gnd 0.1 f 0.1 f dxcvr optional disable 10base2 dc/dc convertor 10base2 mau coax tap (bnc) see am7996 data sheet for component and implementation details active high active low rj45 connector 40.2 ? 40.2 ? 40.2 ? td+ td- rd+ rd- 1 2 3 6 16235d-17 am7996 notes: 1. compatible filter modules, with a brief description of package type and features are included in the following section. 2. the resistor values are recommended for general purpose use and should allow compliance to the 10base-t specification for tem plate fit and jitter performance. however, the overall performance of the transmitter is also affected by the transmit filter configu ration. all resistors are 1%. 3. compatible aui transformer modules, with a brief description of package type and features are included in the following secti on. 4. active high indicates the external convertor should be turned off. the disable transceiver (dxcvr) output is used to indicate the active network port. a high level indicates the 10base-t port is selected and the aui port is disabled. a low level indicates the aui port is selected and the twisted pair interface is disabled. active low: indicates the external converter should be turned off. the lnkst output can be used to indicate the active network port. a high level indicates the 10base-t port is in the link fail state, and the external convertor should be on. a low level indicates the 10base-t port is in the link pass state, and the external convertor should be off. 1:1 1:1 note 4 10base ? t and 10base2 configuration of am79c940
87 xmt filter rcv filter anlg gnd anlg +5 v avss avdd 0.1 f filter & transformer module note 1 note 2 am79c940 txp+ txd- txp- txd+ rxd+ rxd- dgtl gnd 0.1 f lnkst link ok dgtl +5 v rxpol rx pol ok 1.21k ? 100 ? 61.9 ? 422 ? 61.9 ? 422 ? di+ di- ci+ ci- do+ pulse transformer note 3 40.2 ? optional anlg gnd 0.1 f 0.1 f aui connector rj45 connector 40.2 ? 40.2 ? 40.2 ? td+ td- rd+ rd- 1 2 3 6 16235d-18 3 10 5 12 2 9 notes : 1. compatible filter modules, with a brief description of package type and features are included in the following sec- tion. 2. the resistor values are recommended for general purpose use and should allow compliance to the 10base-t specification for template fit and jitter performance. however, the overall performance of the transmitter is also affected by the transmit filter configuration. all resistors are 1%. 3. compatible aui transformer modules, with a brief description of package type and features are included in the following section. 1:1 1:1 10base-t and aui implementation of am79c940 do ?
88 mace compatible 10base-t filters and transformers the table below provides a sample list of mace com- patible 10base-t filter and transformer modules available from various vendors. contact the respective manufacturer for a complete and updated listing of components. mace compatible aui isolation transformers the table below provides a sample list of mace com- patible aui isolation transformers available from vendors. contact the respective manufacturer for a complete and updated listing of components . manufacturer part # package filters and transformers filters transformers and choke filters transformers dual chokes filters transformers resistors dual chokes bel fuse a556-2006-de 16 ? pin 0.3 dil bel fuse 0556-2006-00 14 ? pin sip bel fuse 0556-2006-01 14 ? pin sip bel fuse 0556-6392-00 16 ? pin 0.5 dil halo electronics fd02-101g 16 ? pin 0.3 dil halo electronics fd12-101g 16 ? pin 0.3 dil halo electronics fd22-101g 16 ? pin 0.3 dil pca electronics epa1990a 16 ? pin 0.3 dil pca electronics epa2013d 16 ? pin 0.3 dil pca electronics epa2162 16 ? pin 0.3 sip pulse engineering pe-65421 16 ? pin 0.3 dil pulse engineering pe-65434 16 ? pin 0.3 sil pulse engineering pe-65445 16 ? pin 0.3 dil pulse engineering pe-65467 12 ? pin 0.5 smt valor electronics pt3877 16 ? pin 0.3 dil valor electronics fl1043 16 ? pin 0.3 dil manufacturer part # package description bel fuse a553-0506-ab 16 ? pin 0.3 dil 50 h bel fuse s553-0756-ae 16 ? pin 0.3 smd 75 h halo electronics td01-0756k 16 ? pin 0.3 dil 75 h halo electronics tg01-0756w 16 ? pin 0.3 smd 75 h pca electronics ep9531-4 16 ? pin 0.3 dil 50 h pulse engineering pe64106 16 ? pin 0.3 dil 50 h pulse engineering pe65723 16 ? pin 0.3 smt 75 h valor electronics lt6032 16 ? pin 0.3 dil 75 h valor electronics st7032 16 ? pin 0.3 smd 75 h
89 mace compatible dc/dc converters the table below provides a sample list of mace com- patible dc/dc converters available from various ven- dors. contact the respective manufacturer for a complete and updated listing of components. manufacturer contact information contact the following companies for further information on their products. manufacturer part # package voltage remote on/off halo electronics dcu0-0509d 24 ? pin dip 5/-9 no halo electronics dcu0-0509e 24 ? pin dip 5/-9 yes pca electronics epc1007p 24 ? pin dip 5/-9 no pca electronics epc1054p 24 ? pin dip 5/-9 yes pca electronics epc1078 24 ? pin dip 5/-9 yes valor electronics pm7202 24 ? pin dip 5/-9 no valor electronics pm7222 24 ? pin dip 5/-9 yes company us. and domestic asia europe bel fuse phone: fax: (201) 432-0463 (201) 432-9542 852-328-5515 852-352-3706 33-1-69410402 33-1-69413320 halo electronics phone: fax: (415) 969-7313 (415) 367-7158 65-285-1566 65-284-9466 pca electronics (hpc in hong kong) phone: fax: (818) 892-0761 (818) 894-5791 852-553-0165 852-873-1550 33-1-44894800 33-1-42051579 pulse engineering phone: fax: (619) 674-8100 (619) 675-8262 852-425-1651 852-480-5974 353-093-24107 353-093-24459 valor electronics phone: fax: (619) 537-2500 (619) 537-2525 852-513-8210 852-513-8214 49-89-6923122 49-89-6926542
90 absolute maximum ratings storage temperature . . . . . . . . . . . . -65 c to +150 c ambient temperature . . . . . . . . . . . . . . . . . . . . . . . . . under bias . . . . . . . . . . . . . . . . . . . . . . . 0 c to +70 c supply voltage to avss or dvss (avdd, dvdd) . . . . . . . . . . .-0.3 v to +6.0 v stresses above those listed under absolute maximum rat- ings may cause permanent device failure. functionality at or above these limits is not implied. exposure to absolute max- imum ratings for extended periods may affect device reliabil- ity. programming conditions may differ. operating ranges commercial (c) devices ambient temperature (t a ) . . . . . . . . . . .0 c to +70 c industrial (i) devices ambient temperature (t a ) . . . . . . . . . ? 40 c to +85 c v cc supply voltages . . . . . . . . . . . . . . . . . . . . . . (avdd, dvdd) 5 v 5% all inputs within the range: . . avdd ? 0.5 v vin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . avss + 0.5 v, or . . . . . . . . . . . . . . . . . . . . . . . . . dv dd ? 0.5 v vin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .dv ss + 0.5 v operating ranges define those limits between which the func- tionality of the device is guaranteed. dc characteristics (unless otherwise noted, parametric values are the same between commercial devices and industrial devices.) parameter symbol parameter description test conditions min max unit v il input low voltage 0.8 v v ih input high voltage 2.0 v v ilx xtal1 input low voltage (external clock signal) v ss = 0.0 v ? 0.5 0.8 v v ihx xtal1 input high voltage (external clock signal) v ss = 0.0 v v dd ? 0.8 v dd+ 0.5 v v ol output low voltage i ol = 3.2 ma 0.45 v v oh output high voltage i oh = -0.4 ma (note 1) 2.4 v i il1 input leakage current v dd = 5 v, v in = 0 v (note 2) ? 10 10 a i il2 input leakage current v dd = 5 v, v in = 0 v (note 2) ? 200 200 a i ih input leakage current v dd = 5 v, v in = 2.7 v (note 3) ? 100 a i iaxd input current at di+ and di ? ? 1 v < v in < av dd + 0.5 v ? 500 +500 a i iaxc input current at ci+ and ci ? ? 1 v < v in < av dd + 0.5 v ? 500 +500 a i ilxn xtal1 input low current during normal operation v in = 0 v sleep = high ? 92 (note 9) a i ihxn xtal1 input high current during normal operation v in = 5.5 v sleep = high 92 (note 10) a i ilxs xtal1 input low current during sleep v in = 0 v sleep = low <10 a i ihxs xtal1 input high current during sleep v in = 5.5 v sleep = low 410 a i oz output leakage current 0.4 v < v out < v dd (note 4) ? 10 10 a v aod differential output voltage |(do+) ? (do ? )| r l = 78 ? 630 1200 mv v aodoff transmit differential output idle voltage r l = 78 ? (note 5) ? 40 +40 mv
91 dc characteristics (continued) parameter symbol parameter description test conditions min max unit i aodoff transmit differential output idle current r l = 78 ? ? 1+1ma v aocm do common mode output voltage r l = 78 ? 2.5 avdd v v od i do differential output voltage imbalance r l = 78 ? (note 6) ? 25 25 mv v ath receive data differential input threshold r l = 78 ? (note 6) ? 35 35 mv v asq di and ci differential input threshold squelch r l = 78 ? (note 6) ? 160 ? 275 mv v irdvd di and ci differential mode input voltage range 1.5 v v icm di and ci input bias voltage i in = 0 ma av dd ? 3.0 av dd ? 0.8 v v opd di undershoot voltage at zero differential on transmit return to zero (etd) (note 5) ? 100 mv i dd power supply current sclk = 25 mhz xtal1 = 20 mhz 75 ma i ddsleep power supply current sleep asserted, awake = 0 rwake = 1 (note 7) 100 a i ddsleep power supply current sleep asserted, awake = 1 rwake = 0 (note 7) 10 ma i ddsleep power supply current sleep asserted, awake = 0 rwake = 1 (note 7) 20 ma twisted pair interface i irxd input current at rxd av ss < v in < av dd ? 500 500 a r rxd rxd differential input resistance (note 8) 10 k ? v tivb rxd , rxd ? open circuit input voltage (bias) i in = 0 ma av dd ? 3.0 av dd ? 1.5 v v tidv differential mode input voltage range (rxd ) av dd = +5v ? 3.1 +3.1 v v tsq+ rxd positive squelch threshold (peak) sinusoid 5 mhz f 10 mhz 300 520 mv v tsq ? rxd negative squelch threshold (peak) sinusoid 5 mhz f 10 mhz ? 520 ? 300 mv v ths+ rxd post-squelch positive threshold (peak) sinusoid 5 mhz f 10 mhz 150 293 mv v ths ? rxd post-squelch negative threshold) (peak) sinusoid 5 mhz f 10 mhz ? 293 ? 150 mv v ltsq+ rxd positive squelch threshold (peak) lrt = low 180 312 mv v ltsq ? rxd negative squelch threshold (peak) lrt = low ? 312 ? 180 mv v lths+ rxd post-squelch positive threshold (peak) lrt = low 90 156 mv
92 dc characteristics (continued) notes: 1. v oh does not apply to open-drain output pins. 2. i il1 and i il2 applies to all input only pins except di , ci , and xtal1. i il1 = add4 ? 0, be 1 ? 0, cs , eam/r , fds , reset , rxdat, r/w, sclk. i il2 =tc , tdi, tck, tms. 3. specified for input only pins with internal pull-ups: tc, tdi, tck, tms. 4. i oz applies to all three-state output pins and bi-directional pins. 5. test not implemented to data sheet specification. 6. tested, but to values in excess of limits. test accuracy not sufficient to allow screening guard bands. 7. during the activation of sleep : ? the following pins are placed in a high impedance state: srd, sf/bd, txdat, dxcvr, dtv , tdtreq , rdtreq , ntr and tdo. ? the following i/o pins are placed in a high impedance mode and have their internal ttl level translators disabled: dbus15 ? 0, eof , srdclk, rxcrs, rxdat, clsn, txen , stdclk and txdat+. ? the following input pin has its internal pull-up and ttl level translator disabled: tc . ? the following input pins have their internal ttl level translators disabled and do not have internal pull-ups: cs , fds , r/w , add4-0, sclk, be0 , be1 and eam/r . ? the following pins are pulled low: xtal1 (xtal2 feedback is cut off from xtal1), txd+, txd ? , txp+, txp ? , do+ and do. ? the following pins have their input voltage bias disabled: di+, di, ci+ and ci. ? awake and rwake are reset to zero. i ddsleep, with either awake set or rwake set, will be much higher and its value remains to be determined. 8. parameter not tested. 9. for industrial temperature version, max value is ? 150 a. 10. for industrial temperature version, max value is +150 a. parameter symbol parameter description test conditions min max unit v lths ? rxd post-squelch negative threshold (peak) lrt = low ? 156 ? 90 mv v rxdth rxd switching threshold (note 4) ? 35 35 mv v txh txd and txd output high voltage dv ss = 0v dv dd ? 0.6 dv dd v v txl txd and txd output low voltage dv dd = +5v dv ss dv ss + 0.6 v v txi txd and txd differential output voltage imbalance ? 40 +40 mv v txoff txd and txd idle output voltage dv dd = +5v 40 mv r tx txd differential driver output impedance (note 8) 40 ? txd differential driver output impedance (note 8) 80 ?
93 ac characteristics (unless otherwise noted, parametric values are the same between commercial devices and industrial devices.) notes: 1. the following biu timing assumes that edsel = 1. therefore, these parameters are specified with respect to the falling edge of sclk (sclk ). if edsel = 0, the same parameters apply but should be referenced to the rising edge of sclk ). 2. tested with c l set at 100 pf and derated to support the indicated distributed capacitive load. see the biu output valid delay vs. load chart. 3. guaranteed by design ? not tested. 4. t datd is defined as the time required for outputs to turn high impedence and is not referred to as output voltage lead. no. parameter symbol parameter description test conditions min (ns) max (ns) clock and reset timing 1t sclk sclk period 40 1000 2t sclkl sclk low pulse width 0.4*t sclk 0.6*t sclk 3t sclkh sclk high pulse width 0.4*t sclk 0.6*t sclk 4t sclkr sclk rise time 5 5t sclkf sclk fall time 5 6t rst reset pulse width 15*t sclk 7t bt network bit time (bt)=2*tx1 or tstdc 99 101 internal mendec clock timing 9t x1 xtal1 period 49.995 50.005 11 t x1h xtal1 high pulse width 20 12 t x1l xtal1 low pulse width 20 13 t x1r xtal1 rise time 5 14 t x1f xtal1 fall time 5 biu timing (note 1) 31 t adds address valid setup to sclk 9 32 t addh address valid hold after sclk 2 1. 33 t slvs cs or fds and tc , be 1 ? 0, r/w setup to sclk 9 34 t slvh cs or fds and tc , be 1 ? 0, r/w hold after sclk 2 35 t datd data out valid delay from sclk c l = 100 pf (note 2) 32 36 t dath data out valid hold from sclk 6 37 t dtvd dtv valid delay from sclk c l = 100 pf (note 2) 32 38 t dtvh dtv valid hold after sclk 6 39 t eofd eof valid delay from sclk c l = 100 pf (note 2) 32 40 t eofh eof output valid hold after sclk 6 41 t csis cs inactive prior to sclk 9 42 t eofs eof input valid setup to sclk 9 43 t eofh eof input valid hold after sclk 2 44 t rdtd rdtreq valid delay from sclk c l = 100 pf (note 2) 32 45 t rdth rdtreq input valid hold after sclk 6 46 t tdtd tdtreq valid delay from sclk c l = 100 pf (note 2) 32 47 t tdth tdtreq input valid hold after sclk 6 48 t dats data in valid setup to sclk 9 49 t datih data in valid setup after sclk 2 50 t date data output enable delay from sclk (note 3) 0 51 t datd data output disable delay from sclk (note 3, 4) 25
94 ac characteristics (continued) no. parameter symbol parameter description test conditions min (ns) max (ns) aui timing 53 t dotd xtal1 (externally driven) to do ???? 100 54 t dotr do rise time (10% to 90%) 2.5 5.0 55 t dotf do fall time (10% to 90%) 2.5 5.0 56 t doetm do rise and fall mismatch 1 57 t doetd do end of transmit delimiter 200 375 58 t pwrdi di pulse width to reject |input| > | vasq |15 59 t pwodi di pulse width to turn on internal di carrier sense |input| > | vasq |45 60 t pwmdi di pulse width to maintain internal di carrier sense on |input| > | vasq | 45 136 61 t pwkdi di pulse width to turn internal di carrier sense off |input| > | vasq |200 62 t pwrci ci pulse width to reject |input| > | vasq |10 63 t pwoci ci pulse width to turn on internal sqe sense |input| > | vasq |26 64 t pwmci ci pulse width to maintain internal sqe sense on |input| > | vasq |2690 65 t pwkci ci pulse width to turn internal sqe sense off |input| > | vasq |160 66 t sqed ci sqe test delay from o inactive |input| > | vasq | 67 t sqel ci sqe test length |input| > | vasq | 79 t clshi clsn high time t stdc + 30 80 t txh txen or do hold time from clsn |input| > | vasq | 32*t stdc 96*t stdc dai port timing 70 t txend stdclk delay to txen c l = 50 pf 70 72 t txdd stdclk delay to txdat change c l = 50 pf 70 80 t txh txen or txdat hold time from clsn 32*t stdc 96*t stdc 95 t dotf mismatch in stdclk to txen and txdat change 15 96 t txdtr txdat rise time see note 1 5 97 t txdtf txdat fall time see note 1 5 98 t txdtm txdat rise and fall mismatch see note 1 1 99 t txenetd txen end of transmit delimiter 250 350 100 t frxdd first rxdat delay to rxcrs 100 101 t lrxdd last rxdat delay to rxcrs 120 102 t crsclsd rxcrs delay to clsn (txen = 0) 100
95 ac characteristics (continued) note: 1. not tested but data available upon request. no. parameter symbol parameter description test conditions min (ns) max (ns) gpsi clock timing 17 t stdc stdclk period 99 101 18 t stdcl stdclk low pulse width see note 1 45 19 t stdch stdclk high pulse width 45 20 t stdcr stdclk rise time see note 1 5 21 t stdcf stdclk fall time see note 1 5 22 t srdc srdclk period 85 115 23 t srdch srdclk high pulse width 38 24 t srdcl srdclk low pulse width 38 25 t srdcr srdclk rise time see note 1 5 26 t srdcf srdclk fall time see note 1 5 gpsi timing 70 t txend stdclk delay to txen (c l = 50 pf) 70 71 t txenh txen hold time from stdclk (c l = 50 pf) 5 72 t txdd stdclk delay to txdat+ change (c l = 50 pf) 70 73 t txdh txdat+ hold time from stdclk (c l = 50 pf) 5 74 t rxdr rxdat rise time see note 1 8 75 t rxdf rxdat fall time see note 1 8 76 t rxdh rxdat hold time (srdclk to rxdat change) 25 77 t rxds rxdat setup time (rxdat stable to srdclk ) 0 78 t crsl rxcrs low time t stdc + 20 79 t clshi clsn high time t stdc + 30 80 t txh txen or txdat hold time from clsn 32*t stdc 96*t stdc 81 t crsh rxcrs hold time from srdclk 0 eadi feature timing 85 t dsfbdr srdclk delay to sf/bd 20 86 t dsfbdf srdclk delay to sf/bd 20 87 t eamris eam/r invalid setup prior to srdclk after sfd ? 150 88 t eams eam setup to srdclk at bit 6 of source address byte 1 (match packet) 0 89 t eamr l eam/r low time 200 90 t sfbdhih sf/bd high hold from last srdclk 100 91 t ears ear setup srdclk at bit 6 of message byte 64 (reject normal packet) 0
96 ac characteristics (continued) note: 1. not tested but data available upon request. no. parameter symbol parameter description test conditions min max ieee 1149.1 timing 109 t tclk tck period, 50% duty cycle (+5%) 100 110 t su1 tms setup to tck 8 111 t su2 tdi setup to tck 5 112 t hd1 tms hold time from tck 5 113 t hd2 tdi hold time from tck 10 114 t d1 tck delay to tdo 30 115 t d2 tck delay to system output 35 10base ? t transmit timing min max 125 t tetd transmit start of idle 250 350 126 t tr transmitter rise time (10% to 90%) 5.5 127 t tf transmitter fall time (90% to 10%) 5.5 128 t tm transmitter rise and fall time mismatch 1 129 t xmton xmt# asserted delay 100 130 t xmtoff xmt# de-asserted delay tbd tbd 131 t perlp idle signal period 8 24 132 t pwlp idle link pulse width (note 1) 75 120 133 t pwplp predistortion idle link pulse width (note 1) 45 55 134 t ja transmit jabber activation time 20 150 135 t jr transmit jabber reset time 250 750 136 t jrec transmit jabber recovery time (minimum time gap between transmitted packets to prevent jabber activation) 1.0 10base ? t receive timing 140 t pwnrd rxd pulse width not to turn off internal carrier sense vin > vths (min) 136 ? 141 t pwroff rxd pulse width to turn off vin> vths (min) 200 142 t retd receive start of idle 200 143 t rcvon rcv# asserted delay t ron ? 50 t ron ? 100 144 t rcvoff rcv# de-asserted delay tbd tbd
97 biu output valid delay vs. load chart key to switching waveforms nom+4 nom nom-4 nom-8 50 75 100 125 150 biu output valid delay from sclk (ns) c l (pf) 16235d-19 must be steady may change from h to l may change from l to h does not apply don ? t care, any change permitted will be steady will be changing from h to l will be changing from l to h changing, state unknown center line is high- impedance ? off ? state waveform inputs outputs ks000010
98 switching test circuits c l v threshold i ol i oh normal and three-state outputs 16235d-20 sense point av dd do+ 154 ? 100 pf do- av ss 52.3 ? te s t p o i n t 16235d-21 aui do switching test circuit dv dd txd+ 294 ? 100 pf txd- dv ss 294 ? tes t p o in t includes test jig capacitance 16235d-22 txd switching test circuit
99 dv dd txp+ 715 ? 100 pf txp- dv ss 715 ? tes t p o i nt includes test jig capacitance 16235d-23 txp outputs test circuit sclk 2 1 3 4 5 12 9 11 13 14 6 reset xtal1 clock and reset timing ac waveforms 16235d-24
100 34 sclk (edsel = 1) s3 s2 s1 s0 th tl 32 dbus[15:0] s0 s2 s1 s3 add[4:0] r/w s2 s1 s3 s0 dtv eof 31 word n word n+1 last byte or word s0 33 34 35 37 36 38 40 39 41 cs or fds tc = 1 be0-1 sclk (edsel = 0) s3 s2 s1 s0 th tl s0 s2 s1 s3 s2 s1 s3 s0 s0 51 50 ac waveforms host system interface ? 2-cycle receive fifo/register read timing 16235d-25
101 41 dbus[15:0] add[4:0] r/w dtv eof 36 31 word n word n+1 last byte or word sclk (edsel = 1) s3 s2 s1 s0 th tl s0 w0 s1 s3 s2 s1 s3 s0 s0 w0 w1 w1 s2 w0 w1 be0-1 tc = 0 cs or fds 37 40 34 33 35 32 34 39 38 sclk (edsel = 0) s3 s2 s1 s0 th tl s0 w0 s1 s3 s2 s1 s3 s0 s0 w0 w1 w1 s2 w0 w1 50 51 ac waveforms host system interface ? 3-cycle receive fifo/register read timing 16235d-26
102 sclk (edsel = 1) r/w dtv eof word n word n+1 last byte or word 33 48 49 41 43 31 32 34 s3 s2 s1 s0 th tl s0 s2 s1 s3 s2 s1 s3 s0 s0 38 42 cs or fds dbus15 ? 0 add4 ? 0 34 be0-1 tc = 1 37 s3 s2 s1 s0 th tl s0 s2 s1 s3 s2 s1 s3 s0 s0 sclk (edsel = 0) ac waveforms host system interface ? 2-cycle transmit fifo/register write timing 16235d-27
103 34 word n word n+1 last byte or word 41 32 42 31 s3 s2 s1 s0 th tl s0 s2 s1 s3 s1 s0 w1 w0 w1 w0 s2 s3 s0 w1 w0 sclk (edsel = 1) r/w dtv eof dbus[15:0] add[4:0] be0-1 tc = 0 33 48 49 37 34 43 38 s3 s2 s1 s0 th tl s0 s2 s1 s3 s1 s0 w1 w0 w1 w0 s2 s3 s0 w1 w0 sclk (edsel = 0) cs ac waveforms host system interface ? 3-cycle transmit fifo/register write timing 16235d-28 eof rdtreq 39 44 sclk (edsel = 1) s0 s2 s1 s3 s2 s1 s0 s2 s1 s3 s0 s0 s3 s2 45 note 1 40 sclk (edsel = 0) s0 s2 s1 s3 s2 s1 s0 s2 s1 s3 s0 s0 s3 s2 note: once the host detects the eof output active from the mace device (s2/s3 edge), if no other receive packet exists in the rcvfifo which meets the assert conditions for rdtreq , the mace device will deassert rdtreq within 4 sclk cycles (s0/s1 edge). this is consistent for both 2 or 3 cycle read operations . 16235d-29 host system interface ? rdtreq read timing
104 sclk (edsel = 1) eof tdtreq 43 42 note 1 47 note 3 note 2 s3 s2 s1 s0 s2 s1 s3 s2 s1 s3 s0 s0 s2 s1 s3 s0 46 s3 s2 s1 s0 s2 s1 s3 s2 s1 s3 s0 s0 s2 s1 s3 s0 sclk (edsel = 0) ac waveforms notes: 1. tdtreq will be asserted for two write cycles (4 sclk cycles) minimum. 2. tdtreq will deassert 1 sclk cycle after eof is detected (s2/s3 edge). 3. when eof is written, tdtreq will go inactive for 1 sclk cycle minimum. host system interface ? tdtreq write timing 16235d-30 xtal1 stdclk txdat+ do+ do ? do 53 0 11 0 1 1 1 txen (note 1) 9 54 55 16235d-31 aui transmit timing ? start of packet note: txdat+ is the internal version of the signal, and is shown for clarification only.
105 0 1 0 0 10 bit (n ? 2) bit (n ? 1) bit (n) 1 xtal1 stdclk txdat+ do+ do ? do txen (note 1) > 200 ns 57 16235d-32 note: txdat+ is the internal version of the signal, and is shown for clarification only. aui transmit timing ? end of packet (last bit = 0) 0 1 1 0 1 bit (n ? 2) bit (n ? 1) bit (n) 1 57 xtal1 srdclk txdat+ do+ do ? do txen (note 1) > 250 ns 16235d-33 note: txdat+ is the internal version of the signal, and is shown for clarification only. aui transmit timing ? end of packet (last bit = 1)
106 0 v 100 mv max 40 mv do 57 80 bit times max aui transmit timing ? end transmit delimiter (etd) 16235d-34 di rxcrs ivco srdclk srd ivco_enable (note 1) bcc bcb bcc bcb bcc bcc bcb bcc bcb 5 bit times max (note 2) (note 3) 10 10 10 bit cell 5 bit cell 4 bit cell 3 bit cell 2 bit cell 1 v asq 59 60 16235d-35 notes : 1. minimum pulse width>45 ns with amplitude > ? 160 mv. 2. srd first decoded bit might not be defined until bit time 5. 3. first valid data bit. 4. ivco and vco enable are internal signals shown for clarification only. aui receive timing ? start of packet
107 di rxcrs ivco srdclk (note 1) bcc bcb bit cell (n ? 1) bcc bcb 10 bit cell (n) bit (n ? 1) bit (n) (note 2) srd v asq 60 61 16235d-36 notes: 1. rxcrs deasserts in less than 3 bit times after last di rising edge. 2. start of next packet reception (2 bit times). 3. ivco is an internal signal shown for clarification only. aui receive timing ? end of packet (last bit = 0) di rxcrs ivco s rdclk srd (note 1) bcc bcb bit cell (n ? 1) bcc 01 bit cell (n) bit (n ? 1) bit (n) 61 notes: 1. rxcrs deassets in less than 3 bit times after last di rising edge. 2. ivco is an internal signal shown for clarification only. 16235d-37 aui receive timing ? end of packet (last bit = 1)
108 do 80 clsn ci+ ci- txen 79 aui collision timing 16235d-38 clsn = 0 do ci+ ci- 66 67 aui sqe test timing 16235d-39
109 95 txdat txdat- txdat+ txen stdclk 72 bcb bcb bcb bcb bcb bcb bcb bcb 72 96 97 99 dai port transmit timing 16235d-40 100 rxdat rxcrs 101 dai port receive timing 16235d-41
110 txdat+ 102 clsn rxdat rxcrs txen 79 txdat- dai port collision timing 16235d-42 srdclk srd sfd bit 0 bit 1 bit 2 bit 3 bit 4 bit 5 bit 6 bit 7 bit 0 destination address byte 1 destination address byte 2 eam/r sf/bd 85 note 1 87 86 89 16235d-43 eadi feature timing ? start of address note: first assertion of eam/r must occur after bit 2/3 boundary of preamble.
111 85 srdclk srd sf/bd 86 90 last byte of message eadi feature ? end of packet timing 16235d-44 srdclk srd sf/bd source address byte 2 eam bit 0 bit 1 bit 2 bit 3 bit 4 bit 5 bit 6 bit 7 bit 0 bit 5 bit 6 bit 7 destination address byte 6 source address byte 1 89 88 85 86 eadi feature-match timing 16235d-45
112 rdclk srd sf/bd byte 66 (data byte 53) ear byte 64 (data byte 51) byte 65 (data byte 52) 91 85 89 86 bit 0 bit 1 bit 2 bit 3 bit 4 bit 5 bit 6 bit 7 bit 0 bit 5 bit 6 bit 7 bit 4 bit 1 eadi feature reject timing 16235d-46 stdclk txdat+ txen rxcrs 72 73 20 21 19 18 17 71 70 note 1 gpsi transmit timing 16235d-47 note: during transmit, the rxcrs input must be asserted (high) and remain active-high after txen goes active (high). if rxcrs is deasserted before txen is deasserted, lcar will be reported (transmit frame status) after the transmission is completed by the mace device.
113 77 75 22 78 81 74 76 srdclk rxdat rxcrs 23 24 26 25 16235d-48 gpsi receive timing 79 80 70 72 73 stdclk txdat+ txen clsn 16235d-49 gpsi collision timing
114 tsu1 thd1 td1 tck tms tdo system output tdi tsu2 thd2 td2 16235d-50 ieee 1149.1 tap timing 16235d-51 t xmtoff t tf t tetd note: 1. parameter is internal to the device. t tf 10base-t transmit timing
115 rxcrs rxd t rcvoff t rcvon v tsq+ v tsq- 16235d-52 10base-t receive timing txd clsn t coloff rxd t colon 16235d-53 10base-t collision timing
116 txd+ t perlp t pwlp t pwplp txp+ txd- txp- 16235d-54 10base-t idle link test pulse rxd v tsq+ v tsq- v ths- v ths+ 16235d-55 10base-t receive thresholds (lrt = 0) rxd v ltsq+ v ltsq- v lths- v lths+ 16235d-56 10base-t receive thresholds (lrt = 1)
117 physical dimensions* pl 084 84-pin plastic leaded chip carrier (measured in inches) top view seating plane 1.185 1.195 1.150 1.156 pin 1 i.d. .026 .032 .050 ref .042 .056 .062 .083 .013 .021 1.000 ref .007 .013 .165 .180 .090 .130 side view 1.185 1.195 1.150 1.156 1.090 1.130
118 physical dimensions* pqr100 100-pin plastic quad flat pack; trimmed and formed (measured in millimeters) 0.22 0.38 13.90 14.10 17.10 17.30 18.85 ref 19.90 20.10 23.00 23.40 0.65 basic pin 1 i.d. 12.35 ref 2.70 2.90 3.35 max 0.70 0.90 0.25 min top view side view 17198a cg 47 7/14/92 sg 30 50 80 100
119 physical dimensions pqr100 100-pin plastic quad flat pack with molded carrier ring (measured in millimeters) pin 1 i.d. 19.80 20.10 27.87 28.13 31.37 31.63 35.87 36.13 13.80 14.10 25.20 bsc 27.87 28.13 31.37 31.63 35.50 35.90 35.87 36.13 .65 nom .65 typ .65 pitch .45 typ 2.00 4.80 1.80 side view 17198a cb 48 6/25/92 sg 0.22 0.38 25.15 25.25 22.15 22.25 35.50 35.90 25.15 25.25 22.15 22.25 30 50 80 100 top view
120 physical dimensions* pqt080 80-pin thin quad flat package (measured in millimeters) 13.80 14.20 11.80 12.20 13.80 14.20 11.80 12.20 1 80 1.00 ref. 1.20 max 11 ? ? 13 ? 11 ? ? 13 ? 0.50 bsc .95 1.05
appendix a am79c940 121 logical address filtering for ethernet the purpose of logical (or group or multicast) ad dresses is to allow a group of nodes in a network to receive the same message. each node can maintain a list of multicast addresses that it will respond to. the logical address filter mechanism in amd ethernet con- trollers is a hardware aide that reduces the average amount of host computer time required to determine whether or not an incoming packet with a multicast des tination address should be accepted. the logical address filter hardware is an implementa- tion of a hash code searching technique commonly used by software programmers. if the multicast bit in the destination address of an incoming packet is set, the hardware maps this address into one of 64 catego- ries then accepts or rejects the packet depending on whether or not the bit in the logical address filter regis- ter corresponding the selected category is set. for ex ample, if the address maps into category 24, and bit 24 of the logical address filter register is set, the packet is accepted. since there are more than 10 14 possible multicast ad dresses and only 64 categories, this scheme is far from unambiguous. this means that the software will still have to compare the address of a received packet with its list of acceptable multicast addresses to make the final decision whether to accept or discard the packet. however, the hardware prevents the software from having to deal with the vast majority of the unac ceptable packets. the efficiency of this scheme depends on the number of multicast groups that are used on a particular net- work and the number of groups to which a node be longs. at one extreme if a node happens to belong to 64 groups that map into 64 different categories, the hardware will accept all multicast addresses, and all fil- tering must be done by software. at the other extreme (which is closer to a practical network), if multicast ad dresses are assigned by the local administrator, and fewer than 65 groups are set up, the addresses can be assigned so that each address maps into a different category, and no software filtering will be needed at all. in the latter case described above, a node can be made a member of several groups by setting the appropriate bits in the logical address filter register. the administra- tor can use the table mapping of logical address to fil ter mask to find a multicast address that maps into a particular address filter bit. for example address 0000 0000 00bb maps into bit 15. therefore, any node that has bit 15 set in its logical address filter register will re ceive all packets addressed to 0000 0000 00bb. (addresses in this table are not shown in the standard ethernet format. in the table the rightmost byte is the first byte to appear on the network with the least signif icant bit appearing first). driver software that manages a list of multicast ad dresses can work as follows. first the multicast ad dress list and the logical address filter must be ini tialized. some sort of management function such as the driver initialization routine passes to the driver a list of addresses. for each address in the list the driver uses a subroutine similar to the one listed in the am7990 lance data sheet to set the appropriate bit in a software copy of the logical address filter register. when the complete list of addresses has been pro cessed, the register is loaded. later, when a packet is received, the driver first looks at the individual/group bit of the destination address of the packet to find out whether or not this is a multicast address. if it is, the driver must search the multicast ad dress list to see if this address is in the list. if it is not in the list, the packet is discarded. the broadcast address, which consists of all ones is a special multicast address. packets addressed to the broadcast address must be received by all nodes. since broadcast packets are usually more common than other multicast packets, the broadcast address should be the first address in the multicast address list.
122 am79c940 mapping of logical address to filter mask byte # bit # ladrf bit destination address accepted byte # bit # ladrf bit destination address accepted 0 0 0 85 00 00 00 00 00 4 0 32 21 00 00 00 00 00 0 1 1 a5 00 00 00 00 00 4 1 33 01 00 00 00 00 00 0 2 2 e5 00 00 00 00 00 4 2 34 41 00 00 00 00 00 0 3 3 c5 00 00 00 00 00 4 3 35 71 00 00 00 00 00 0 4 4 45 00 00 00 00 00 4 4 36 e1 00 00 00 00 00 0 5 5 65 00 00 00 00 00 4 5 37 c1 00 00 00 00 00 0 6 6 25 00 00 00 00 00 4 6 38 81 00 00 00 00 00 0 7 7 05 00 00 00 00 00 4 7 39 a1 00 00 00 00 00 1 0 8 2b 00 00 00 00 00 5 0 40 8f 00 00 00 00 00 1 1 9 0b 00 00 00 00 00 5 1 41 bf 00 00 00 00 00 1 2 10 4b 00 00 00 00 00 5 2 42 ef 00 00 00 00 00 1 3 11 6b 00 00 00 00 00 5 3 43 cf 00 00 00 00 00 1 4 12 eb 00 00 00 00 00 5 4 44 4f 00 00 00 00 00 1 5 13 cb 00 00 00 00 00 5 5 45 6f 00 00 00 00 00 1 6 14 8b 00 00 00 00 00 5 6 46 2f 00 00 00 00 00 1 7 15 bb 00 00 00 00 00 5 7 47 0f 00 00 00 00 00 2 0 16 c7 00 00 00 00 00 6 0 48 63 00 00 00 00 00 2 1 17 e7 00 00 00 00 00 6 1 49 43 00 00 00 00 00 2 2 18 a7 00 00 00 00 00 6 2 50 03 00 00 00 00 00 2 3 19 87 00 00 00 00 00 6 3 51 23 00 00 00 00 00 2 4 20 07 00 00 00 00 00 6 4 52 a3 00 00 00 00 00 2 5 21 27 00 00 00 00 00 6 5 53 83 00 00 00 00 00 2 6 22 67 00 00 00 00 00 6 6 54 c3 00 00 00 00 00 2 7 23 47 00 00 00 00 00 6 7 55 e3 00 00 00 00 00 3 0 24 69 00 00 00 00 00 7 0 56 cd 00 00 00 00 00 3 1 25 49 00 00 00 00 00 7 1 57 ed 00 00 00 00 00 3 2 26 09 00 00 00 00 00 7 2 58 ad 00 00 00 00 00 3 3 27 29 00 00 00 00 00 7 3 59 8d 00 00 00 00 00 3 4 28 a9 00 00 00 00 00 7 4 60 0d 00 00 00 00 00 3 5 29 89 00 00 00 00 00 7 5 61 2d 00 00 00 00 00 3 6 30 c9 00 00 00 00 00 7 6 62 6d 00 00 00 00 00 3 7 31 e9 00 00 00 00 00 7 7 63 4d 00 00 00 00 00
appendix b am79c940 123 bsdl description of am79c940 mace jtag structure -- -------- 04 november 1996 ----------- -- jwb 13-aug-1996 changed "tqfp_package" to "tqfp" -- 31-oct-1996 corrected reversed bit subscripts for add, dbus ! -- and bumped chip rev version from 2 to 3 -- a separate file for tqfp only, had to be created due to the missing -- four pins/functions on the tqfp version. -- the compiler does not know how to handle the missing four pins/functions -- in the tqfp version while at the same time, available for the pqfp -- and plcc versions. we have no further plans for going back to -- combining both files into a single bsdl file. -- network products division product marketing group -- ------------------------------------- -- bsdl file created/edited by at&t bsd editor -- -- bsde:revision: silicon rev. c0; file rev a3 -- bsde:description: bsdl file for the am79c940 mace rev c0 product -- bsde:comments: /* bsdl file for the tqfp definition only. -- * bsdl file checked by at&t?s bcad2 bsd editor on 04/03/96 -- */ entity am79c940 is generic (physical_pin_map : string := "tqfp" ); port ( add: in bit_vector (4 downto 0); avdd1: linkage bit; avdd2: linkage bit; avdd3: linkage bit; avdd4: linkage bit;
124 am79c940 avss1: linkage bit; avss2: linkage bit; be0_l: in bit; be1_l: in bit; ci0: linkage bit; ci1: in bit; clsn: inout bit; cs_l: in bit; dbus: inout bit_vector (15 downto 0); di0: linkage bit; di1: in bit; do0: linkage bit; do1: out bit; dvdd1: linkage bit; dvdd2: linkage bit; dvddn: linkage bit; dvddp: linkage bit; dvss1: linkage bit; dvss2: linkage bit; dvssn1: linkage bit; dvssn2: linkage bit; dvssn3: linkage bit; dvssp: linkage bit; dxrcv_l: out bit; eam_r_l: in bit; edsel: in bit; eof_l: inout bit; fds_l: in bit; intr_l: out bit; lnkst_l: out bit; rdtreq_l: out bit; reset_l: in bit; rxcrs: inout bit; rxd0: linkage bit; rxd1: in bit; rxdat: inout bit; r_w_l: in bit; sclk: in bit; sf_bd: out bit;
am79c940 125 sleep_l: in bit; srdclk: inout bit; stdclk: inout bit; tck: in bit; tc_l: in bit; tdi: in bit; tdo: out bit; tdtreq_l: out bit; tms: in bit; txd0: linkage bit; txd1: out bit; txdat1: inout bit; txen_l: inout bit; txp0: linkage bit; txp1: out bit; xtal1: in bit; xtal2: linkage bit ); use std_1149_1_1990.all; attribute pin_map of am79c940 : entity is physical_pin_map; constant tqfp: pin_map_string:= "add:(40,39,38,37,36)," & "avdd1:52," & "avdd2:57," & "avdd3:64," & "avdd4:69," & "avss1:59," & "avss2:61," & "be0_l:31," & "be1_l:32," & "ci0:67," & "ci1:68," & "clsn:78," & "cs_l:42," & "dbus:(27,26,24,23,22,21,20,19,18,17," & "16,14,13,12,11,9)," &
126 am79c940 "di0:65," & "di1:66," & "do0:62," & "do1:63," & "dvdd1:49," & "dvdd2:70," & "dvddn:25," & "dvddp:6," & "dvss1:47," & "dvss2:73," & "dvssn1:10," & "dvssn2:15," & "dvssn3:28," & "dvssp:75," & "dxrcv_l:71," & "eam_r_l:2," & "edsel:72," & "eof_l:29," & "fds_l:30," & "intr_l:7," & "lnkst_l:43," & "rdtreq_l:35," & "reset_l:4," & "rxcrs:80," & "rxd0:50," & "rxd1:51," & "rxdat:79," & "r_w_l:41," & "sclk:33," & "sf_bd:3," & "sleep_l:5," & "srdclk:1," & "stdclk:76," & "tck:46," & "tc_l:8," & "tdi:48," & "tdo:44," & "tdtreq_l:34," & "tms:45," &
am79c940 127 "txd0:54," & "txd1:56," & "txdat1:74," & "txen_l:77," & "txp0:53," & "txp1:55," & "xtal1:58," & "xtal2:60"; attribute tap_scan_in of tdi : signal is true; attribute tap_scan_out of tdo : signal is true; attribute tap_scan_mode of tms : signal is true; attribute tap_scan_clock of tck : signal is (1.00e+07, both); attribute instruction_length of am79c940 : entity is 4; attribute instruction_opcode of am79c940 : entity is "bypass ( 0110, 0111, 1000, 1001, 1010, 1011, 1100, 1101, 1110," & " 1111)," & "extest ( 0000)," & "idcode ( 0001)," & "sample ( 0010)," & "selftst ( 0101)," & "setbyp ( 0100)," & "tribyp ( 0011)" ; attribute instruction_capture of am79c940 : entity is "0001"; attribute instruction_disable of am79c940 : entity is "tribyp"; attribute instruction_private of am79c940 : entity is " selftst"; attribute idcode_register of am79c940 : entity is "0011" &---- version 31-oct-1996 bumped version from 2 to 3 ! "1001010000000000" &--- part number "00000000001" &---- manufacturer?s id "1";----- required by standard attribute register_access of am79c940 : entity is
128 am79c940 "bypass ( bypass, setbyp, tribyp)," & "boundary ( extest, sample, selftst)," & "idcode ( idcode)"; attribute boundary_cells of am79c940 : entity is " bc_1, bc_4"; attribute boundary_length of am79c940 : entity is 99; attribute boundary_register of am79c940 : entity is " 0 (bc_1, *, control, 0)," & " 1 (bc_1, lnkst_l, output3, x, 0, 0, weak1)," & " 2 (bc_1, *, internal, 0)," & " 3 (bc_1, cs_l, input, 1)," & " 4 (bc_1, r_w_l, input, 1)," & " 5 (bc_1, add(4), input, 0)," & " 6 (bc_1, add(3), input, 0)," & " 7 (bc_1, add(2), input, 0)," & " 8 (bc_1, add(1), input, 0)," & " 9 (bc_1, add(0), input, 0)," & " 10 (bc_1, *, control, 0)," & " 11 (bc_1, rdtreq_l, output3, x, 10, 0, z)," & " 12 (bc_1, tdtreq_l, output3, x, 10, 0, z)," & " 13 (bc_4, sclk, clock, 1)," & " 14 (bc_1, be1_l, input, 1)," & " 15 (bc_1, be0_l, input, 1)," & " 16 (bc_1, fds_l, input, 1)," & " 17 (bc_1, *, internal, 0)," & " 18 (bc_1, *, internal, 0)," & " 19 (bc_1, *, control, 0)," & " 20 (bc_1, eof_l, output3, x, 19, 0, z)," & " 21 (bc_1, eof_l, input, 1)," & " 22 (bc_1, *, control, 0)," & " 23 (bc_1, dbus(15), output3, x, 22, 0, z)," & " 24 (bc_1, dbus(15), input, 0)," & " 25 (bc_1, dbus(14), output3, x, 22, 0, z)," & " 26 (bc_1, dbus(14), input, 0)," & " 27 (bc_1, dbus(13), output3, x, 22, 0, z)," & " 28 (bc_1, dbus(13), input, 0)," &
am79c940 129 " 29 (bc_1, dbus(12), output3, x, 22, 0, z)," & " 30 (bc_1, dbus(12), input, 0)," & " 31 (bc_1, dbus(11), output3, x, 22, 0, z)," & " 32 (bc_1, dbus(11), input, 0)," & " 33 (bc_1, dbus(10), output3, x, 22, 0, z)," & " 34 (bc_1, dbus(10), input, 0)," & " 35 (bc_1, *, control, 0)," & " 36 (bc_1, dbus(9), output3, x, 35, 0, z)," & " 37 (bc_1, dbus(9), input, 0)," & " 38 (bc_1, dbus(8), output3, x, 35, 0, z)," & " 39 (bc_1, dbus(8), input, 0)," & " 40 (bc_1, dbus(7), output3, x, 35, 0, z)," & " 41 (bc_1, dbus(7), input, 0)," & " 42 (bc_1, dbus(6), output3, x, 35, 0, z)," & " 43 (bc_1, dbus(6), input, 0)," & " 44 (bc_1, dbus(5), output3, x, 35, 0, z)," & " 45 (bc_1, dbus(5), input, 0)," & " 46 (bc_1, dbus(4), output3, x, 35, 0, z)," & " 47 (bc_1, dbus(4), input, 0)," & " 48 (bc_1, dbus(3), output3, x, 35, 0, z)," & " 49 (bc_1, dbus(3), input, 0)," & " 50 (bc_1, dbus(2), output3, x, 35, 0, z)," & " 51 (bc_1, dbus(2), input, 0)," & " 52 (bc_1, dbus(1), output3, x, 35, 0, z)," & " 53 (bc_1, dbus(1), input, 0)," & " 54 (bc_1, dbus(0), output3, x, 35, 0, z)," & " 55 (bc_1, dbus(0), input, 0)," & " 56 (bc_1, tc_l, input, 1)," & " 57 (bc_1, *, control, 0)," & " 58 (bc_1, intr_l, output3, 1, 57, 0, weak1)," & " 59 (bc_1, sleep_l, input, 1)," & " 60 (bc_1, reset_l, input, 1)," & " 61 (bc_1, *, control, 0)," & " 62 (bc_1, sf_bd, output3, x, 61, 0, z)," & " 63 (bc_1, *, internal, 0)," & " 64 (bc_1, eam_r_l, input, 0)," & " 65 (bc_1, *, control, 0)," & " 66 (bc_1, srdclk, output3, x, 65, 0, z)," & " 67 (bc_1, srdclk, input, 0)," &
130 am79c940 " 68 (bc_1, *, control, 0)," & " 69 (bc_1, rxcrs, output3, x, 68, 0, z)," & " 70 (bc_1, rxcrs, input, 0)," & " 71 (bc_1, *, control, 0)," & " 72 (bc_1, rxdat, output3, x, 71, 0, z)," & " 73 (bc_1, rxdat, input, 0)," & " 74 (bc_1, *, control, 0)," & " 75 (bc_1, clsn, output3, x, 74, 0, z)," & " 76 (bc_1, clsn, input, 0)," & " 77 (bc_1, *, control, 0)," & " 78 (bc_1, txen_l, output3, x, 77, 0, z)," & " 79 (bc_1, txen_l, input, 0)," & " 80 (bc_1, *, control, 0)," & " 81 (bc_1, stdclk, output3, x, 80, 0, z)," & " 82 (bc_1, stdclk, input, 0)," & " 83 (bc_1, *, control, 0)," & " 84 (bc_1, *, internal, 0)," & " 85 (bc_1, txdat1, output3, x, 83, 0, z)," & " 86 (bc_1, txdat1, input, 1)," & " 87 (bc_1, edsel, input, 1)," & " 88 (bc_1, *, control, 0)," & " 89 (bc_1, dxrcv_l, output3, x, 88, 0, z)," & " 90 (bc_4, xtal1, clock, 0)," & " 91 (bc_1, rxd1, input, 1)," & " 92 (bc_1, *, control, 0)," & " 93 (bc_1, txp1, output3, x, 92, 0, z)," & " 94 (bc_1, txd1, output3, x, 92, 0, z)," & " 95 (bc_1, *, control, 0)," & " 96 (bc_1, do1, output3, x, 95, 0, z)," & " 97 (bc_4, di1, input, 1)," & " 98 (bc_4, ci1, input, 1)"; end am79c940; =============================================================================
am79c940 131 -- -- bsdl file created/edited by at&t bsd editor -- -- bsde:revision: silicon rev. c0; file rev a3 -- bsde:description: bsdl file for the am79c940 mace product; -- 84-pin plcc and 100-pin pqfp packages. -- separate file for 80-pin tqfp package. -- bsde:comments: /* tqfp definition has been deleted. -- * bsdl file checked by at&t?s bcad2 bsd editor on 9/7/95 -- */ entity am79c940 is generic (physical_pin_map : string := "plcc_package" ); port ( add: in bit_vector (0 to 4); avdd1: linkage bit; avdd2: linkage bit; avdd3: linkage bit; avdd4: linkage bit; avss1: linkage bit; avss2: linkage bit; be0_l: in bit; be1_l: in bit; ci0: linkage bit; ci1: in bit; clsn: inout bit; cs_l: in bit; dbus: inout bit_vector (0 to 15); di0: linkage bit; di1: in bit; do0: linkage bit; do1: out bit; dtv_l: out bit; dvdd1: linkage bit; dvdd2: linkage bit; dvddn: linkage bit; dvddp: linkage bit;
132 am79c940 dvss1: linkage bit; dvss2: linkage bit; dvssn1: linkage bit; dvssn2: linkage bit; dvssn3: linkage bit; dvssp: linkage bit; dxrcv_l: out bit; eam_r_l: in bit; edsel: in bit; eof_l: inout bit; fds_l: in bit; intr_l: out bit; lnkst_l: out bit; rdtreq_l: out bit; reset_l: in bit; rxcrs: inout bit; rxd0: linkage bit; rxd1: in bit; rxdat: inout bit; rxpol_l: out bit; r_w_l: in bit; sclk: in bit; sf_bd: out bit; sleep_l: in bit; srd: out bit; srdclk: inout bit; stdclk: inout bit; tck: in bit; tc_l: in bit; tdi: in bit; tdo: out bit; tdtreq_l: out bit; tms: in bit; txd0: linkage bit; txd1: out bit; txdat0: out bit; txdat1: inout bit; txen_l: inout bit; txp0: linkage bit;
am79c940 133 txp1: out bit; xtal1: in bit; xtal2: linkage bit ); use std_1149_1_1990.all; attribute pin_map of am79c940 : entity is physical_pin_map; constant plcc_package: pin_map_string:= "add:(49,50,51,52,53)," & "avdd1:66," & "avdd2:71," & "avdd3:78," & "avdd4:83," & "avss1:73," & "avss2:75," & "be0_l:44," & "be1_l:45," & "ci0:81," & "ci1:82," & "clsn:9," & "cs_l:55," & "dbus:(21,23,24,25,26,28,29,30,31,32," & "33,34,35,36,38,39)," & "di0:79," & "di1:80," & "do0:76," & "do1:77," & "dtv_l:42," & "dvdd1:63," & "dvdd2:84," & "dvddn:37," & "dvddp:18," & "dvss1:61," & "dvss2:3," & "dvssn1:22," & "dvssn2:27," & "dvssn3:40," &
134 am79c940 "dvssp:6," & "dxrcv_l:1," & "eam_r_l:13," & "edsel:2," & "eof_l:41," & "fds_l:43," & "intr_l:19," & "lnkst_l:57," & "rdtreq_l:48," & "reset_l:16," & "rxcrs:11," & "rxd0:64," & "rxd1:65," & "rxdat:10," & "rxpol_l:56," & "r_w_l:54," & "sclk:46," & "sf_bd:15," & "sleep_l:17," & "srd:14," & "srdclk:12," & "stdclk:7," & "tck:60," & "tc_l:20," & "tdi:62," & "tdo:58," & "tdtreq_l:47," & "tms:59," & "txd0:68," & "txd1:70," & "txdat0:5," & "txdat1:4," & "txen_l:8," & "txp0:67," & "txp1:69," & "xtal1:72," & "xtal2:74"; constant pqfp_package: pin_map_string:=
am79c940 135 "add:(46,47,48,49,50)," & "avdd1:67," & "avdd2:72," & "avdd3:83," & "avdd4:88," & "avss1:74," & "avss2:79," & "be0_l:41," & "be1_l:42," & "ci0:86," & "ci1:87," & "clsn:98," & "cs_l:56," & "dbus:(14,16,17,18,19,21,22,23,24,25," & "29,31,32,33,35,36)," & "di0:84," & "di1:85," & "do0:81," & "do1:82," & "dtv_l:39," & "dvdd1:64," & "dvdd2:89," & "dvddn:34," & "dvddp:11," & "dvss1:62," & "dvss2:92," & "dvssn1:15," & "dvssn2:20," & "dvssn3:37," & "dvssp:95," & "dxrcv_l:90," & "eam_r_l:6," & "edsel:91," & "eof_l:38," & "fds_l:40," & "intr_l:12," & "lnkst_l:58," & "rdtreq_l:45," & "reset_l:9," &
136 am79c940 "rxcrs:100," & "rxd0:65," & "rxd1:66," & "rxdat:99," & "rxpol_l:57," & "r_w_l:55," & "sclk:43," & "sf_bd:8," & "sleep_l:10," & "srd:7," & "srdclk:5," & "stdclk:96," & "tck:61," & "tc_l:13," & "tdi:63," & "tdo:59," & "tdtreq_l:44," & "tms:60," & "txd0:69," & "txd1:71," & "txdat0:94," & "txdat1:93," & "txen_l:97," & "txp0:68," & "txp1:70," & "xtal1:73," & "xtal2:75"; attribute tap_scan_in of tdi : signal is true; attribute tap_scan_out of tdo : signal is true; attribute tap_scan_mode of tms : signal is true; attribute tap_scan_clock of tck : signal is (1.00e+07, both); attribute instruction_length of am79c940 : entity is 4; attribute instruction_opcode of am79c940 : entity is "bypass ( 0110, 0111, 1000, 1001, 1010, 1011, 1100, 1101, 1110," & " 1111)," & "extest ( 0000)," & "idcode ( 0001)," &
am79c940 137 "sample ( 0010)," & "selftst ( 0101)," & "setbyp ( 0100)," & "tribyp ( 0011)" ; attribute instruction_capture of am79c940 : entity is "0001"; attribute instruction_disable of am79c940 : entity is "tribyp"; attribute instruction_private of am79c940 : entity is " selftst"; attribute idcode_register of am79c940 : entity is "0011" &-- version "1001010000000000" &-- part number "00000000001" &-- manufacturer?s id "1";-- required by standard attribute register_access of am79c940 : entity is "bypass ( bypass, setbyp, tribyp)," & "boundary ( extest, sample, selftst)," & "idcode ( idcode)"; attribute boundary_cells of am79c940 : entity is " bc_1, bc_4"; attribute boundary_length of am79c940 : entity is 99; attribute boundary_register of am79c940 : entity is " 0 (bc_1, *, control, 0)," & " 1 (bc_1, lnkst_l, output3, x, 0, 0, weak1)," & " 2 (bc_1, rxpol_l, output3, x, 0, 0, weak1)," & " 3 (bc_1, cs_l, input, 1)," & " 4 (bc_1, r_w_l, input, 1)," & " 5 (bc_1, add(4), input, 0)," & " 6 (bc_1, add(3), input, 0)," & " 7 (bc_1, add(2), input, 0)," & " 8 (bc_1, add(1), input, 0)," & " 9 (bc_1, add(0), input, 0)," &
138 am79c940 " 10 (bc_1, *, control, 0)," & " 11 (bc_1, rdtreq_l, output3, x, 10, 0, z)," & " 12 (bc_1, tdtreq_l, output3, x, 10, 0, z)," & " 13 (bc_4, sclk, clock, 1)," & " 14 (bc_1, be1_l, input, 1)," & " 15 (bc_1, be0_l, input, 1)," & " 16 (bc_1, fds_l, input, 1)," & " 17 (bc_1, *, control, 0)," & " 18 (bc_1, dtv_l, output3, x, 17, 0, z)," & " 19 (bc_1, *, control, 0)," & " 20 (bc_1, eof_l, output3, x, 19, 0, z)," & " 21 (bc_1, eof_l, input, 1)," & " 22 (bc_1, *, control, 0)," & " 23 (bc_1, dbus(15), output3, x, 22, 0, z)," & " 24 (bc_1, dbus(15), input, 0)," & " 25 (bc_1, dbus(14), output3, x, 22, 0, z)," & " 26 (bc_1, dbus(14), input, 0)," & " 27 (bc_1, dbus(13), output3, x, 22, 0, z)," & " 28 (bc_1, dbus(13), input, 0)," & " 29 (bc_1, dbus(12), output3, x, 22, 0, z)," & " 30 (bc_1, dbus(12), input, 0)," & " 31 (bc_1, dbus(11), output3, x, 22, 0, z)," & " 32 (bc_1, dbus(11), input, 0)," & " 33 (bc_1, dbus(10), output3, x, 22, 0, z)," & " 34 (bc_1, dbus(10), input, 0)," & " 35 (bc_1, *, control, 0)," & " 36 (bc_1, dbus(9), output3, x, 35, 0, z)," & " 37 (bc_1, dbus(9), input, 0)," & " 38 (bc_1, dbus(8), output3, x, 35, 0, z)," & " 39 (bc_1, dbus(8), input, 0)," & " 40 (bc_1, dbus(7), output3, x, 35, 0, z)," & " 41 (bc_1, dbus(7), input, 0)," & " 42 (bc_1, dbus(6), output3, x, 35, 0, z)," & " 43 (bc_1, dbus(6), input, 0)," & " 44 (bc_1, dbus(5), output3, x, 35, 0, z)," & " 45 (bc_1, dbus(5), input, 0)," & " 46 (bc_1, dbus(4), output3, x, 35, 0, z)," & " 47 (bc_1, dbus(4), input, 0)," & " 48 (bc_1, dbus(3), output3, x, 35, 0, z)," &
am79c940 139 " 49 (bc_1, dbus(3), input, 0)," & " 50 (bc_1, dbus(2), output3, x, 35, 0, z)," & " 51 (bc_1, dbus(2), input, 0)," & " 52 (bc_1, dbus(1), output3, x, 35, 0, z)," & " 53 (bc_1, dbus(1), input, 0)," & " 54 (bc_1, dbus(0), output3, x, 35, 0, z)," & " 55 (bc_1, dbus(0), input, 0)," & " 56 (bc_1, tc_l, input, 1)," & " 57 (bc_1, *, control, 0)," & " 58 (bc_1, intr_l, output3, 1, 57, 0, weak1)," & " 59 (bc_1, sleep_l, input, 1)," & " 60 (bc_1, reset_l, input, 1)," & " 61 (bc_1, *, control, 0)," & " 62 (bc_1, sf_bd, output3, x, 61, 0, z)," & " 63 (bc_1, srd, output3, x, 61, 0, z)," & " 64 (bc_1, eam_r_l, input, 0)," & " 65 (bc_1, *, control, 0)," & " 66 (bc_1, srdclk, output3, x, 65, 0, z)," & " 67 (bc_1, srdclk, input, 0)," & " 68 (bc_1, *, control, 0)," & " 69 (bc_1, rxcrs, output3, x, 68, 0, z)," & " 70 (bc_1, rxcrs, input, 0)," & " 71 (bc_1, *, control, 0)," & " 72 (bc_1, rxdat, output3, x, 71, 0, z)," & " 73 (bc_1, rxdat, input, 0)," & " 74 (bc_1, *, control, 0)," & " 75 (bc_1, clsn, output3, x, 74, 0, z)," & " 76 (bc_1, clsn, input, 0)," & " 77 (bc_1, *, control, 0)," & " 78 (bc_1, txen_l, output3, x, 77, 0, z)," & " 79 (bc_1, txen_l, input, 0)," & " 80 (bc_1, *, control, 0)," & " 81 (bc_1, stdclk, output3, x, 80, 0, z)," & " 82 (bc_1, stdclk, input, 0)," & " 83 (bc_1, *, control, 0)," & " 84 (bc_1, txdat0, output3, x, 83, 0, z)," & " 85 (bc_1, txdat1, output3, x, 83, 0, z)," & " 86 (bc_1, txdat1, input, 1)," & " 87 (bc_1, edsel, input, 1)," &
140 am79c940 " 88 (bc_1, *, control, 0)," & " 89 (bc_1, dxrcv_l, output3, x, 88, 0, z)," & " 90 (bc_4, xtal1, clock, 0)," & " 91 (bc_1, rxd1, input, 1)," & " 92 (bc_1, *, control, 0)," & " 93 (bc_1, txp1, output3, x, 92, 0, z)," & " 94 (bc_1, txd1, output3, x, 92, 0, z)," & " 95 (bc_1, *, control, 0)," & " 96 (bc_1, do1, output3, x, 95, 0, z)," & " 97 (bc_4, di1, input, 1)," & " 98 (bc_4, ci1, input, 1)"; end am79c940;
appendix c am79c940 141 am79c940 mace rev c0 silicon errata the items below are the known errata for rev c0 silicon. rev c0 is the production silicon. the enclosed is a list of known errata ? s encountered with the mace rev c0 device. each of these errata ? s is pro- vided with description, implication, and workaround (if possible). where the errata was published in a previous er- rata list, is so noted. other than those listed exceptions below that have not been fixed, the mace rev c0 production device is fully functional. the "description" section of the errata gives a brief description of the problem. the "implication" section of the errata describes the effects of the problem in a system configuration. the "workaround" section of the errata de- scribes methods to minimize the system effects. the ? status ? section of the errata describes when and how the problem will be corrected. current package marking for this revision: line 1: line 2: am79c940bkc (assuming package is pqfp) line 3: line 4: (c) 1992 amd value of chipid register for this revision: chipid[15:00] = 3940h 1) receive fragment frame treated as a new packet even after receive fifo overflows: description: the mace device continues to receive the remains of a long packet even after the receive fifo overflows. if this data stream has the ? start of frame ? (sfd) bit pattern "10101011" (and no "00" bit pattern before the "sfd" pattern) and the destination address field of the packet matches the station address after the sfd bit pattern, or if the mace device is in promiscuous mode, the remaining portion of the long packet will be received and treated by the mace device as a new packet even though the receive status will show an fcs error. implication: there is no impact of any kind if the receive fifo overflow is not permitted by the system design. the likelihood of such an occurrence of the above conditions is extremely remote. should this condition occur, this will impact performance only in products using the ? cut-through ? method. this is because the "cut- through" method will not look at the fcs field, which would indicate an error in the packet received. workaround: check for fcs error after the packet is received. status: no current plan to fix this item. 2) in low latency receive mode, loses synchronization when connected to a coaxial transceiver via the aui port: description: in low latency receive mode, the mace device loses synchronization when connected to a co- axial (10base2) transceiver. the problem occurs when connecting the mace to a coaxial transceiver via the aui interface, and at the same time the mace device is programmed into low latency receive mode. when a collision occurs in the media and if mace device continues to receive data, after the collision is ended, the mace device loses synchronization. implication: no performance impact to the mace device if the 10base-t port is used instead of a 10base2 coaxial transceiver connected to the aui port of the mace device. workaround: this condition is being validated at this time. in the meantime, it is recommended that if the product is to be used in a network topology where a 10base2 coaxial transceiver is connected to the aui port, care must be exercised to avoid using the mace device in low latency receiver mode.
142 am79c940 status: no current plan to fix this item. 3) flashing led for link status: description: when tmau receiver is receiving negative polarity link pulse, and the automatic polarity correc- tion algorithm (dapc bit in phy configuration control register) is disabled, link test state machine will loop between ? link fail ? and ? link pass ? state causing the link status led to flash. implication: there is no impact to system performance. however, the link status led flashing may cause an erroneous interpretation by the user. workaround: there is no workaround. status: no current plan to fix this item. 4) incorrect runt packet count in low latency receive mode: description: in low latency receive mode, the mace runt packet count is incremented when the receive packet is less than 12 bytes. the correct runt packet count should always be incremented when the receive packet is less than 64 bytes. implication: there is no impact on system performance if the runt packet count is not being utilized by the system. workaround: this condition is being validated at this time. therefore, a workaround for this is to be deter- mined. 5) device failure at 1.25 mhz system clock: description: mace device does not function reliability at system clock speed of less than 5mhz due to ar- chitecture constraints. implication: there is no performance impact since the serial clock is still running at the ieee specified 10mhz. workarounds: 1. avoid operating the mace device at speeds of less than 5mhz. 2. send one packet at a time. essentially, write one packet to the transmit fifo, let the mace device transmit that packet, wait for the transmit complete interrupt, before writing another packet to the transmit fifo. status: no current plan to fix this item. 6) false babl errors generated: description: the mace device will intermittenly give babl error indications when the network traffic has frames equal to or greater than 1518 bytes. implication: false babl errors on the receiving station can be passed up to the upper layer software if mace device is just coming out of deferral and the multi-purpose counter used to count the number of bytes recevied reaches 1518 at the same time. if the network is heavily loaded with full-size frames, then the probability of a false babl error is high. workaround: there are two possible workarounds. 1. if the user has no intention to transmit frames larger than 1518 bytes, then the babl bit may be masked to ignore babble errors. in this case the false babble error will not cause an interrupt, nor will it be passed to the higher level software. 2. check to see if the device is transmitting in isr (interrupt service routine), which is induced by the babl error. the bcrs which control the led settings can be programmed to indicate a transmit ac- tivity, assuming the interrupt latency is not longer than one mininum ifg (inter-frame gap) time.
am79c940 143 if (isr_latency < 9.6 us) true_bable_err = babl * ( tint + xmt_led) { i.e. false_bable_err = ~ (babl * ( tint + xmt_led))} else cannot tell if the babl error is true or false just by reading babl, tint, xmt_led bits in isr. status: no current plan to fix this item.
144 am79c940

▲Up To Search▲

Price & Availability of AM79C940JIW

	To Download AM79C940JIW Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .